►
From YouTube: GraphQL js Working Group - 2020 11 25
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
B
A
A
B
A
B
A
B
B
B
A
C
A
A
B
A
A
A
A
A
Actually,
yeah
like
sorry
to
everybody,
I
just
confused
times,
so
that's
why
it's
like
yeah,
I
think
like
we
need
to
create
calendar
to
not
count
everyone
to
not
a
recurring
current
data
when
to
not
have
it
in
the
future.
To
save
me
from
and
everybody
else
from
same
situation,
so
yeah
I
will
add
agenda
one
thing
I
don't
know
if
yeah,
so
I
will
send
it
one
more
time.
A
A
Graphql
foundation
ask
everybody
to
sign
membership
argument,
so
if
you
want
to
participate
in
this
course,
you
need
to
sign
code
of
conduct
participation,
guidelines.
Everything
is
agenda.
You
can
sign,
it
is
like
as
a
person
or
as
organization,
but
it's
simply
to
just
send
it
as
individual
contributors.
By
the
way.
A
quick,
quick
note,
I
think,
like
brian
from
graphical
foundation,
he
is
introducing
automatic
coa
check.
So
at
some
point
we
would
stop
merging
vrs
without
a
coa
signed,
because
we
need
to
do
it
for
legal
reason.
A
A
A
A
A
A
A
So
yeah,
I
didn't
finish
like
bunch
of
others
and
I
I
still
need
to
work
on
it
yeah,
but
at
least
like
you
will,
when
we
will
have
when
we
agree
on
test
migration
point,
it
will
unblock
me
partly
because
yeah
and
we
can
work
in
parallel.
So
I
will
focus
on
probably
writing
contribution
guide
to
the
next
item.
A
So
like
goals
of
16,
so
it's
not
only
this
test
migration
pawn
on
previous
meeting.
We
all
agreed
that
it
makes
sense
to
do
test
conversion
as
a
breaking
change
as
a
new
release,
because
it
will
make
conversion
more
flexible
and
it
will
like
will
probably
break
something
anyway,
so
yeah
so
in
scope
of
v6
and
zero
zero
release
convert.
A
A
So
it
should
contain
the
smallest
possible
amount
of
javascript,
specific
workarounds
and
javascript
specific
stuff,
but
at
the
same
time
it
should
be
like
usable
and
provide
a
good
developer
experience
for
javascript,
so
javascript
like
users.
That's
why
we
will
add,
like
some
some
typescript,
specifically
so
workarounds,
but
we
should
try
to
minimize
it.
So
if
something
is
not
hurting
or
developer
experience,
we
should
remove
it
support
dinner,
because
people
start
asking
about
that
and
one
of
them
broadbox
biggest
roadblock
for
that.
It's
like
having
typescript.
A
So,
like
sometimes
forks
make
sense,
but
if
we
can
incorporate
new
platform,
why
not
so
in
addition
to
node
and
browser
will
support,
you
know,
support
asm,
because
the
same
people
asking
for
that
and
finally
node.js
is
finalized
on
the
asm
design.
So
previously
we
support
like
partly
supported
sm
through
mjs
files,
but
it's
incomplete
and
we
need
to
figure
out
what.
A
A
A
Yes,
do
you
hear
me
yeah
yeah,
oh
super
yeah,
so
yes,
which
means
to
master,
because
we
need
to
do
it
anyway
and
because
right
now
is
feature
freeze,
let's
make
sense.
If
we
walk
like
the
hours,
I
think
it's
the
safest
time
to
do
wet
switch
and
if
yeah
and
plus,
like
usual,
one
stuff
that
we
planned
anyway
for
this
release.
So.
A
A
A
A
Next
year,
in
the
middle
of
next
year,
because
we
need
to
drop
not
version
10.
previously,
we
tried
to
support
old,
node
versions
after
after
otc
ended,
but
it's
hard
because
everybody
is
dropping.
So
we
kind
of
also
need
to
to
stay
in
sync
with
our
other
libraries,
or
we
would
have
problem
of
updating
dependencies
so
based
on
current
goal
and
a
fact
that
we
will
release
next
one
in
less
than
a
year.
A
A
So
idea
is
to
keep
it
minimal,
because
in
a
sense
it's
not
one
breaking
release.
We
didn't
want
to
do
it,
but
because
of
this
conversion,
we
need
to
do
it.
So
that's
why
I
will
just
change
and
somebody
just
to
check
if,
like
my
setup
is
working,
can
somebody
say
something
yeah
yeah.
I
could
hear
you:
okay,
okay,
so
yeah,
it's
always
hard
to
to
do
one
monologues.
A
So
if
you
want
to
ask
something
or
suggest
something
so
one
breaking
change
is
to
drop,
like
I
say,
hdl
syntax,
because
it
was
deprecated
for
more
than
two
years
and
it
makes
sense
to
drop
it
instead
of
converting
it
and
some
other
so
vegas
is
the
syntax
is
the
biggest
duplicated
stuff
that
we
currently
have.
We
have
some
other
like
minor,
duplicated
stuff,
that
most
of
them
are
quite
easy
to
migrate.
A
So,
like
second,
it's,
it's
also
kind
of
big
to
drop
native
internet
explorer
support
because
it's
make
contribution,
process
harder
and
reviewing
process
harder.
I
constantly
need
to
review
cars
and
see
if
people
using
e6,
something
that
is
not
supported
in
the
internet
explorer
and
we
have
like
a
handwritten
polyfills.
A
A
We
use
a
bunch
of
we
had
like
inject
much
of
third
party
code,
but
at
the
same
time,
if
somebody
wants
to
to
use
coaches
and
bubble
on
our
source
code,
we
should
support
this.
We
should
support
that
use
case
for
some
time,
so
it's
mean
like
we
cannot
use
like
stuff.
That
is
not
political
or
is
not
like
transformed
by
bubble
in
ideal
situation.
A
We
needed
because
we
want
to
use
recursive
types
and
in
our
typings,
otherwise
we
fall
supported,
recursive
types
and
for
current
typing
current
dts
files.
We
use
any
in
bunch
of
places
which
is
not
ideal
and
we
kind
of
losing
type
safety
for
our
internal
code
base
compared
to
to
fall
so.
But
if
somebody
like
is,
if
big
group
of
users
cannot
update
to
typescript
3.7,
we
can
try
to
figure
out
some
alternative
paths,
but
by
default
we
should
try
with
updating
to
3.7
passes
like
break
and
release.
A
A
A
So
since
we
try
to
minimize
scope
to
absolute
minimum,
converting
to
just
is
not
breaking
change,
so
we
can
do
it
after
six
point:
zero
point:
zero
release.
We
still
want
to
use
just
because,
like
graphic
data
order,
another
project
is
used
just
so,
I
think
like
we
should.
We
should
have
like
the
same
technical
style
stack,
not
sure
if
we
were
able
like
one
thing
to
research,
if
we
would
be
able
to
run
just
on
the
you
know,
to
run
our
test,
and
you
know.
C
A
Yeah,
so
some
basic
motivation
top
of
the
issue
because,
like
as
a
other
projects
using
just
and
because
in
line
snapshots,
I
don't
think
we
should
use
as
reference
implementation.
We,
I
don't
think
we
should
use
external
snapshots
yeah,
but
annoying
some
shots.
Sometimes
it's
quality
of
life
improvement
not
to
manually
did
stuff.
A
A
About
steps,
what
to
do
so,
I'm
started
like
first
step
is
all
the
steps
is
not
done
yet.
So
it
was
some
preparation
work
before
that
and
right
now
yeah.
But
these
steps
are
starting
from
now.
Basically,
as
subject
is
not
done,
and
first
thing
is,
we
need
to
branch
out
15
x6
release
and
do
the
last
one
release
last
feature
release
in
the
wine,
basically
because
I
forget
to
to
add,
like
some
necessary
stuff
for
for
deprecation
of
arguments
and
input
fields
and
because
we
already
released
it
in
previous
release.
A
Duplication
of
arcs
and
fields,
and
we
need
to
fix
it
because
we
already
release
it.
So
basically,
it's
like
last
thing
for
feature
freeze,
then
switch
master
to
main
and
update
script
cis.
I
think
I
have
like
admin
rights
and
it's
easier
for
me
to
test,
so
I
will
just
run.
Git
grab
master
and
change
it
to
main,
and
one
big
thing
is
to
choose
which
oprs
to
to
main.
A
A
A
He
he
based
his
test
conversion,
pr
on
top
of
it,
so
move
commits
there
to
main
it's
pretty
technical,
because
our
current
change
of
generation
script
is
based
on
prs,
so
I
cannot
just
move
commits.
I
need
to
create
prs
for
them,
but
at
the
same
time,
pairs
is
good
because
people
can
discuss
changes
there.
If
we
like
break
something,
people
have
at
least
a
place
to
ask
questions
about
this
particular
change.
A
A
A
A
A
So
if
you
use
for
typing
in
carcera
or
if
built
using
default
icons,
and
you
need
them,
please
comment
an
issue,
but
basically
we'll
have,
in
theory,
we'll
have
like
four
six
and
zero.
Zero
will
basically
still
have
four
typeings
from
alpha
1
release,
because
esm
and
then
support
is
not
related
to
typings.
A
A
C
A
Only
people
on
the
call-
but
maybe
somebody
watching
in
the
recordings
so
step
on
this
stage,
is
to
review
this
pr.
I'm
personally
like
I'm
this
typescript
user,
but
I'm
not
like,
I
think
enough
for
better
than
typescript
so
definitely
appreciate
like
some
second
pair
of
eyes
on
vr,
but
idea
that
every
commit
is
easily
reviewable.
So
this
commit
is
switch
form
for
syntax,
for
maybe
into
like
our
utility
might
be
type
so
and
all
the
rest
of
commits
like
that.
So
the
easier
review
and.
C
B
Currently,
I
am
just
like
this
week
last
few
weeks,
I
didn't
get
much
time
to
like
work
on
it.
That's
why
I
didn't
push
main
changes,
but
I
think
the
thing
is
left
is
just
fix,
adding
arguments
to
functions
and
then,
and
then,
if
you're
deleting
and
then
they're,
like
a
few
more
small
fixes
like
when
we
compared
our
flow
like
we
we
made,
we
ran
the
flow
tool
to
have
like
in
a
new
branch.
B
We
ran
a
flow
tool
to
compare
what
we
were
doing
manually
with
that
fellow
branch,
and
it
was
quite
close.
We
just
like
I
found
like
five
years
so
far
with
the
yeah.
I
just
found
five
errors
and
I
just
need
to
fix
those
and,
after
that
the
issues
are
like,
I
think,
more
typescript
related
than
like
flow
syntax,
and
I
would
need
help
on
like
how
to
convert
those
specific
issues.
A
Perfect
yeah
so
basically
like
a
goal,
is
to
why
it's
not
paralyzable
at
this
point,
because
it
should
be
reviewable
and
huge
syntax
conversion
done
by
like
people
in
parallel.
It's
it's
hard
to
review.
Basically,
that's
why
right
now,
but
idea
is
since
I
think,
sahid
already
by
wine,
so
by
changes
he
already
did
like
80
90
percent
of
her
work.
A
That
is
done
by
like
with
step
number
five,
so
measured
and
parallel
wise
fixing
typescript
errors,
because
it's
like
way
smaller
pr's
and
they
like
more
unique
in
a
sense.
And
I
don't
expect
it
to
be.
Like
thousands
of
wines,
I
expected
to
be
like
hundreds
of
ones,
so
we
can
figure
out
so
idea
after
replacing
merge,
we
fix
as
much
stuff
as
possible.
A
And
disable
surface
that
is
not
working
so
basically
to
to
fix
ci
and,
like
you
know,
typescript
bubble
setup
like
maybe
still
use
bubble
with
typescript.
Maybe
this
is
just
switch
to
type
script
figure
out
the
like
simplest
way
to
to
start
running
tests
and
ci
and
like
by
the
way
like
managed
to
run
bigger,
so
prettier
is
running
and,
yes,
it
is
running,
but
it's
failing
on
some
typescript
specific
rules.
B
A
A
A
A
A
I
think
it
can
be
paralyzed.
We
will
see
if
like
if
it's
how
it
will
work,
but
the
idea
that
at
this
point
like
people
can
do
do
with
stuff
in
parallel,
and
we
will
clearly
see
the
number
of
errors
I
still
expected
to
be,
like
maybe
hundreds
and
some
of
them
are
connected
to
each
other,
but
I
think,
like
some
of
them
would
be
hard
and
require
a
person
who
knows
typescript
very
well
so
yeah.
A
We
can
ask
for
help
at
this
point,
and
next
step
is
the
same
thing
with
cslint
but
based
on
the
rules.
So,
like
somebody
open
the
pr
to
enable
one
particular
typescript,
specific
cs,
intro
and
fix
all
the
warning
or
disable
some
of
them,
if,
if
he
fix
it,
partly
so
after
we
sure
it's
like
by
the
way.
A
At
this
point
probably
I
need
to
to
write
so
at
this
point
we
fix
all
hanging
fruits
and
if
we
still
stuck
with
some
like
weird
corner
typescript
corner
cases,
we
will
still
release
some
alpha
version
in
ideal
situation.
It
would
be
alpha
2,
but
maybe
we
broke
something
with
alpha
one,
so
it
can
be
like
one
or
five
versions
and
gather
feedback.
So
at
this
point
basically
like
two
checkpoints
checkpoint
is
to
release
alpha
one
with
break
expected,
breaking
changes
and
release
with
away
after
text
conversion
version
and
ask
everybody
to
test
it.
A
Point
like
stuff
that
is
major
and
after
that,
in
parallel
with
feedback,
is
to
work
on
the
assignment.
Then
support
and
both
this
issue
is,
can
be
paralyzed
because
esm
is,
you
can
bring
packaging
dinners
doesn't
use
on
pam
by
the
way
like
graphql
js
is
usable
through
npm
package
edina,
I
think
like
from
pico
pica
cdn,
but
it's
not
native.
So
when
I
say,
like
you
know,
support
I
mean
like
native
support.
A
A
A
So
basically
like
what
what
I
experienced
in
previous
releases,
it's
like
people
want
to
add
like
one
last
breaking
change
before
release,
so
it
prolonged
releases
so
because
of
a
person
the
center.
If
it's
either,
it
said
that
1600
or
you
need
to
wait
like
months
or
years
before
next
release,
so
to
mitigate
what
ideas
to
create
with
experimental
branch.
But
it's
super
unstable,
no
guarantees,
and
it's
even
like
realizable.
A
So
I
didn't
finish
for
that
section
in
time,
so
I
just
create
the
issue
with
stuff
that
I
had
basically
helping
is
reviewing
and
helping
with
next
steps.
I
will
also
think
about
what
what
can
be
done
in
in
parallel
and
how
other
people
can
help.
So
here
I
will
expand
this
section,
so
we
do
have
like
feedback
or
suggestion.
A
So
if
you,
if
somebody
watching
this
recording
and
want
to
add
like
some
big
change,
please
comment,
indonesia
and
we
can
figure
out
how
to
incorporate
bad
feedback
so
yeah.
So
I
think
we
discussed
yeah
and
I
can
stop
stop
sharing
yeah.
So
I
think
we
discussed
like
current
state
of
typescript
conversion,
so
just
to
clarify.
Currently
we
own
15x6
and
master
branches
on
15x6,
and
we
have
16x6
as
a
branch
and
we
have
a
hit
a
branch
on
top
of
16
x6.
A
So
that's
why
it's
hard
right
now,
because
I
replaced
16x6
on
top
of
master
and
saheed
replace
his
branch
on
top
of
the
s16
so
which
that's.
Why
idea
is
to
streamline
it
and
just
even
if
it's
not
finished
pr,
just
to
merge
it
as
is,
and
have
people
help
with
migration?
So
it's
like
a
main
point
of
this
plan.
A
A
A
C
Yeah
what
I
wanted
to
ask
about
so
the
the
workflows
that
we
have
the
the
one
on
graphql
js,
even
though
it's
long
it
has
some
issues
in
there,
for
example,
has
some
name
issues
and
it's
all
compacted
in
one
single
workflow?
It's
not
how
workflows
are
meant
to
to
exist
are
meant
to
like,
sadly,
sadly,
I've
gotten
experience
on
it
for
more
than
five
months,
just
working
on
it.
C
So
it's
like
kind
of
a
pull
and
and
and
to
understand
how
workflows
display
to
the
user
and
also
how
they
look
right
now
so
copying
what
we
have
in
the
in
the
in
the
graph
colleges,
even
though
it
works
there
are
like
everything
is
called
lint,
for
example.
So
the
main
title
on
the
I
can
share
actually.
C
My
entire
idea
was
to
talk
about
if
we
can
create
a
repository
that
is
called
dot
github,
that
what
it
does
is
gives
you
a
template
for
a
standard
workflow,
so
everybody
can
every
instead
of
us
committing
to
every
project.
We
can
just
go
and
say
use
this
workflow,
and
it
will
just
create
a
pr
with
that
workflow
already,
so
we
it
just
kind
of
hands
on
hands
off.
This
is
what
what
I've
done
in
organizations,
because
you
don't.
C
A
C
Yeah,
we
have
a
couple
of
problems
here,
and
this
is
kind
of
what
is
blocking
me
right
now,
so
I
just
want
to
clarify
right
now,
so,
for
example,
this
should
not
be
like
this.
You
should
not
be
triggering
push
and
pull
requests
in
the
same
pr.
This
is
I'm
just
open
the
last
pr
that
I
found
right.
This
is
part
of
the
things
that
you
ivan
was
asking
me
to
do,
and
this
is
exactly
why
I
wasn't
doing
it.
C
This
is
this
is
yeah,
so
this
is
like
what
trying
to
bring
the
the
effort
of
dealing
with
this
nightmare,
because
I
had
the
same
problem
when
I
started,
but
I
see
it
everywhere
and
now
I'm
blocking
this
part
in
in
the
sw
api,
because
you
were
asking
me
to
do
this.
This
is
not
intense
that
you
are
running
twice
everything:
okay,
because
you
are
reacting
to
that
event.
C
There
are
ways
to
help
to
to
fix
it,
mainly
not
using
either
narrowing
down
what
push
does
or
narrowing
down
what
pull
request
does,
but
not
both
as
they
are
right
now.
This
is
what
I
was
trying
to
to
exemplify.
If
you
see
at
the
beginning,
it
says
linked
source
files
and
you're
running
everything
underneath.
C
So
this
is
also
a
problem
with
workflows,
meaning
workflows
are
a
bit
more
complicated
in
the
in
the
nonsense
of
what
it
does.
So
I
I
wanna
I
wanna
I
wanna
propose
to
have
a
single
workflow
as
a
template
and
a
simple
one
that
it
does
the
basic
hooks.
If
you
see
the
agenda,
if
we
go
to
the
agenda
the
agenda
I'm
proposing,
let's
have
the
basic
npm
run,
test,
npm
or
yarn,
run
test
or
sorry
lint
and
build.
C
If
a
build
step
is
probable
and
every
project
can
just
conform
to
that,
and
we
just
don't
think
about
it
that
main
workflow
we
can
later
on.
For
example,
graphql
js
has
more
stuff,
it
does
more
stuff.
We
can
create
a
different
workflow
under
the
directory
that
only
addresses
graphql
js
particularities
in
every
project.
C
We
have
different
projects,
so
at
that
point
we
will
have
always
the
insurance
that
at
least
the
the
simplest
main
workflow
is
going
to
run,
meaning
lint
tests
and
some
build
step,
and
we
and
every
other
project
that
we
have
will
run
everything
else
right.
So
this
is
kind
of
the
idea
that
I
had,
but
I
wanna
I
wanted
to
share,
to
agree
on
this
and
and
make
sure
we
can
fix
this.
I'm
happy
that
I
already
have
the
pr
ready
to
remove
this,
but
I
I
wanted
to
agree
here.
A
Yeah,
like
so
yeah
like
I'm,
totally
agree
with
this
idea.
One
thing
that
I'm
worried
about
with
reusability
and
split
shouldn't
should
solve
more
problems
that
it
introduced.
So
if
we
can
do
that,
I'm
totally
for
it.
So
what
I
suggest
is
since,
like
you,
you
know
about
workforce
and
more
than
me,
I'm
not
like
for
swiping.
For
example,
we.
A
We
don't
have
netlify
config
and
like
netflight
deployment,
it's
its
own
like
stuff,
both
I'm
not
really
familiar
with
swapping,
so
it's
easier
to
review
such
stuff
on
graphql
js,
and
since
it's
also
the
most
complex
workflow
that
we
have
like
one
one
asked
risk.
I
think
we
need
to
to
have
a
clean
goal
of
basic
setup,
basic
like
reusable
setup
for
non-monorepos,
because
I
think,
like
graphical,
have
monorepo
so
for
monorepo.
I
expect
like
maybe.
C
Yes,
and
no
so
I
I
you
do
have
monorepos
in
crosstalk,
we
have
two
big
monorepos
where
two
200
engineers
work
on
them
and
the
workflows
can
be
generic
as
well,
because
every
monorepo
at
least
in
javascript,
you
have
a
packaging
at
the
top
level
that
you
can.
You
can
gather
behavior,
so
you
can
say
that
test
is
running
all
the
tests:
okay,
fireworks
spaces,
so
meaning
the
basic
workflow
that
I'm
talking
about.
That
is
the
simple
one
that
the
only
thing
that
it
does
is:
linting
testing
and
upload,
karkov
and
and
pretty
much
it.
C
Those
that
basic
thing
could
be
a
workflow
that
we
use
everywhere.
So
we
at
least
have
that
insurance
that
we
know
that
a
simple
workflow
is
running
everything
and
then
what
I
was
proposing
is
in
in
the
particular
monorepo
in
particular,
workflows
that
need
really
really
specific
setup
like
running
some
netlife
through
through
the
workflow
or
some
particular
thing
that
I
don't
know
right
now.
C
A
D
A
So
yeah,
because
because
like
what
I
do
personally
for
express
graphql,
for
example,
and
now
what
I
tried
for
away
is
I
I
open
a
gif
for
with
workflow
files
and
I'm
like
putting
like
a
changes
from
graphql
js.
I
always
do
almost
always
you
changes
first
and
graphql
js
and
if
they
make
sense
I
ran
like
through
give
too,
I
was
imported
to
other
repos,
which
is
not
ideal
situation
and
what
this
is
why
I'm
like.
I
want
the
graphql
chest
to
to
use
latest
stuff
and
then
we
can
move
it
to
others
yeah.
A
C
Well,
it's
it's
not
that
not
in
well.
I
don't
know
if
that
what
even
what
what
I
was
proposing
is
action
is
a
different
thing.
It
will
have
actions
are
the
atom
inside
inside,
and
so
the
relationship
is
workflows.
Is
that
file
that
yaml
file?
That
will
tell
you
what
are
the
the
things
that
you're
going
to
trigger
and
inside
our
actions
right,
so
yeah
we're
not,
hopefully
we're
not
going
to
create
any
action.
What
we're
going
to
do?
C
Yeah
there
are
plenty
I
can
look
for
them.
There's
a
github
repo
here
you
see
yeah,
so
this
one
can
have
more
than
the
readme
can
have
not
only
the
the
the
template
for
issues
the
template
for
pull
requests.
You
can
also
have
actions
that
you
can
use
later,
so
you
can
just
go
to
actions
in
in
a
particular
place
and
says
it
will
show
you
here,
a
template.
B
The
issue
with
like
I,
I
don't
think
that
dot
github
updates.
After
the
fact
we
you
created
a
repo
or
does
it
update
it.
So
suppose
I
make
a
new
repo
in
graphical
org
and
I
had
a
few
actions
in
it
and
after
some
time
I
added
a
new
action
in
my
dot
github.
Will
it
update
in
all
the
20
repos
at
graphql
js
or
no
no.
C
C
Well,
at
that
point
at
that
point,
what
what
what
I
end
up
doing
at
that
point
is
create
an
app
and
what
you
do
with
the
github
is
server
side
component
and
that
doesn't
have
anything
in
the
repo
it's
just
code
deployed
somewhere
that
it
will
produce
changes
in
your
repo.
So
it's
a
different
apple
pie
works
this
way.
So
the
idea
is
not
reinvent
the
wheel.
Let's
just
use
what
we
have
right.
C
C
C
A
C
Yeah,
I
understand
what
you
say
and,
and
it's
not
how
it
works.
That's
why
I
want
to
show
you
so
I
can.
This
is
one
repository
that
this
is
one
action
actually
that
I
this
it
doesn't
matter
where
the
code
is,
I'm
just
going
to
show
you
the
workflow,
so
you
can
see
that
you
don't
have
to
worry
about
that.
A
C
I
agree
so
just
showing
you
just
showing
you
things,
so
you
can
I'm
going
to
show
you
one,
I'm
trying
to
look
for
it.
So
let
me
see
aloha.
This
is
the
thing
that
I
wrote
a
long
time
ago.
Let's
see,
I
think
this
one
has
the
workflow
that
we
are
looking
for
validation,
so
this
one
is
only
running
on
pull
request.
Let
me
see
you
can
find
the
one
that
runs
on
push.
I
think
it's
this
one
yeah.
C
C
Yeah,
my
idea
was
just
to
have
it
on
push
every
time,
but
the
problem
is
in
my
workflows.
I
often
do
more
things
in
one
place
than
the
other,
so
I
never
I
I
do
more
things
on
on
pull
requests
than
a
master,
so
I
separate
it
apart
because
I
don't
want
to
do.
You
can
do
ifs
inside
oh
here,
so
I
found
one,
and
this
is
an
action
that
invokes
a
lambda
aws,
that
this
is
an
open
source
thing,
so
you
can
see
that
the
only
validation
that
I
have
run
some
push.
C
C
C
A
C
What
we
can
do
is
if
we
want
to
keep
but
to
be
clear
if
we
want
to
keep
the
pull
request.
The
pull
request
does
all
the
things
that
might
be
useful,
but
we
can
do,
and
this
is
kind
of
the
idea.
What
we
can
do
is
have
both
pull
and
push.
But
what
we
do
is
if
we
narrow
down
what
what
pull
reque
when
when
push
works,
so
push
only
will
trigger
on
master
and
pull
request
will
trigger
on
everything
else.
C
A
C
A
At
that
point,
it's
not
like
in
scope
of
right
now
with
typescript
conversion
stuff,
but
afterwards
to
to
make
it
like
friendly.
We
will
need
to
run
some
linter
or
pr's
to
lean
right,
mid
messages
and
we
can
obviously
cannot
run
into
master,
because
we
already
have
a
bunch
of
commits
that
it's
not
right.
So
I
expect
some
difference
to
happen
in
future,
but
like
we
need,
we
will
deal
with
it
in
future.
So.
C
Yeah
so
so
yeah.
I
want
I'm
more
for
trying
to
simplify
what
we
have
right
now,
so
we
can
copy
paste
more
at
least,
and
we
don't
have
to
duplicate
that
much
so
I
will.
I
will
try
to
to
get
to
a
point
that
we
can
use
it.
Something
that
you
will
see
that
happens
is
when
someone
like
that
is
not
a
collaborator
is
pushing
like
I'm,
not
I'm
just
someone
pushing
code
to
a
branch.
It
will
not
run
a
new
workflow
unless
the
workflow
is
a
master.
A
So
my
only
requirement
is
that,
if
you're,
not
hundred
percent
sure
it's,
I
think
please
test
it
away.
This
will
work
so
as
as
like
action
action
points
until
we
merge
the
hit
pr,
I'm
okay,
with
merging
any
like
improvement
to
our
our
github
actions
files
after
we
merge
the
hit
pr
will
break
action,
and
so
it's
bad
thing
to
fix
them
and
change
them
at
the
same
time.
But
before
that
I
think,
like
we
still
have
a
week,
maybe
more,
like
ideally
less
yeah.
They
will
like
a
week.
A
Please
write
like
explanation,
because
one
thing
not
only
for
me
but
for
people
who
basically
for
blame
to
have
some
meaningful
explanation,
why
we
introduce
something
and
another
point,
I'm
like
I'm
against
personally
against
in
adding
any
dependencies
third-party
dependencies,
oh
yeah,
unless
it's
absolutely
necessary
or
unless
it's
like
widely
used
one.
So
I'm
okay
like
visiting
like
just
and
like
react
and
like
stuff,
but
I'm
like
because
stuff
that,
for
example,
install
packages
it
can
it
can
change
content
of
node
models
and
will
even
cache
it
yeah.
That's.
C
The
the
only
thing
that
I
can
remember
in
my
peers
that
had
that
it
was
a
suggestion
for
from
ricky.
It
wasn't
something
that
I
added
myself
just
trying
to
just
I
I
don't
know,
because
we
don't
have
so
many
so
many
documentation
about
what
we
accept,
what
we
don't
and
and
how
we
are
going
to
do
this.
It's
sometimes
I'm
just
trying
to
navigate
like
anyone
who
comes
from
the
organization
and
says:
oh,
we
use
this.
Oh
wait.
A
Graphical
and
iosp
tricky
maintains
it's
development
only
so
like.
Obviously,
nobody
like
graphical
is
not
production
tools.
It's
like
the
world
contacts
and
like
other
parkings,
is
the
same.
Graphql
js
is
production
stuff,
so
it's
used
by
a
bunch
of
like
airbnb
using
it,
and
it's
used
by
like
entire
power
stack,
is
built
on
everybody.
A
A
For
example,
we
can
support
like
browser
and
node
and
and
dino
and
don't
care
about
bundlers
or
other
like
solutions
so
for
workforce.
I
pass,
we
don't
depend
on
some
like
one
person,
one
person
projects
when
the
person
like
disappear
or
not
update
or
have
security
problems
so
yeah,
it's
like
my
only
and
by
the
way,
if
you
feel
like
somebody,
some
dependency
is
necessary
or
it
makes
sense.
A
A
Fix
stuff
and
improve
by
the
way
about
improvement,
if
you
figure
out
how
to
split
them
into
separate
things,
I'm
like
totally
for
it
right
and
also
about
actions.
I
think,
like
I
wrote
the
show
script
for
checking,
because
people
constantly
is
a
commit
appears
with
idea
like
directory
or
like
some
other
id
directory,
or
they
try
to
add
it
into
git.
Ignore
it's
endless
story.
If
you
start
adding
ideas,
you
constantly
continue
to
add
them.
C
I
read
it,
I
know
what
you're
talking
about
it
could
be
an
action,
it's
not
hard
to
write
them.
I
have
like.
I
have
many
already
that
I
that
I
maintain
by
myself
for
for
coursera,
so
the
problem
with
that
is
that,
when
it's
bash,
the
problem
that
you
have
is
bashes
is
impossible
to
test
really
like
bash
is
not
a
language
that
you
can
test.
You
there's
no
framework
to
test
that.
C
So
if
we
create
that
in
a
separate
action,
the
problem
that
we're
going
to
land
is
is
if
we
use
the
same
code,
is
we're
gonna
have
to
come
up
with
a
testing
framework
to
test
bash,
which
is
not
the
most
comfortable.
So
I
I
tend
to
write
everything
in
typescript,
even
even
if
it's
a
workaround,
so
I
can
test
it.
So
I
can
have
a
typescript,
so
I
can
use
that.
Yes,
if
you
see
my
use
herald
action
that
you
saw
there,
that
is
what
we're
using
monorepos
for
big
organizations
in
private.
C
A
A
It's
like
makes
sense
to
merge
it,
so
we
don't
have
tests
for
this
section
right
now
and
if
we
separate
it,
we
will
also
not
have
tests
for
it,
so
we
don't
lose
anything
and
I'm
definitely
open
to.
If
somebody
wants
to
rewrite
it,
I'm
also
open
one
thing
to
keep
in
mind:
it's
like
it's
not
hard
requirement.
A
A
Like
for
most
part,
we
should
focus
on
our
own
use
cases,
so,
like
graphql
foundation
is
created
to
show
graphical
cases,
so
we
can
open
source
or
extract
something
to
be
usable
by
people
at
the
same
time.
It's
okay!
If
not,
we
don't
care
if
it's
so
our
own
problem.
So
like
this
particular
action
like,
let's
don't
think
about
it
as
as
or
our
workforce,
let's
not
think
about
it
as
like
solution
for
for
javascript
ecosystem
or
like
github
action
like
a
system
but
solution
for
like
foundation.
C
A
Have
enough
time
to
update
it,
so
he
updated
once
a
year.
So
if
something
is
happening,
we
basically
stack
zero,
so
so
families
factor.
If
if
something
can
be
done
and
like
tens
of
wines,
it
makes
sense
and
big
changes
is
not
expected.
So
we
don't
expect
it
change
frequently
so
vendor
it
is
actually
a
solution.
For
example,
I
change
work
generation-
I
I
wrote
it
like
in
in
a
day
and
it's
work
good.
It's
like
optimized
to
our
use
case
our
setup
and
I
don't
change
it
like
often.
A
A
C
A
C
A
Yeah,
I
actually
added
one
topic
yeah
about
next
steps,
because
it's
always
good
to
define,
so
we
try
to
contribute
as
much
as
possible
fix
it
before
we
match
the
hit
pr.
If,
if
you
want
to
do
something
afterwards,
we
can
choose
any
other
repo
is
a
test
ground
like,
for
example,
we
can
use
or
create
branch
or
use
like,
for
example,
data
order
as
test
ground.
A
A
So,
like
I
would
say,
minimal
valuable
thing
would
be
cleaning
up,
krafkeljs,
workflows
next
step
is
to
have
like
common
or
reusable
stuff
for
non-monorepo
and
if
we
can
fit
like
one
rip
and
graphical
at
the
same
time,
it's
like
ideal
use
case.
So,
let's,
let's
proceed
that
way,
fix
craftkiljs
and
like
generalize
and
then
figure
out
how
to
integrate
it,
and
with
this
graphical.
C
All
right
sounds
good
sounds
good.
I
can
talk
to
rick
as
well.
I've
been
talking
to
him
lately,
so
I
can
talk
to
him
about
about
this
idea
of
merging
workflows
and
trying
to
have
the
minimal.
So
don't
worry
about
it
all
right.
I
have
to
drop
off,
but
thank
you
and
I
I
will
follow
up
with
all
the
things
that
we
have
talked
about.