►
From YouTube: 2022-02-16-Next 10 years of Node.js
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
So
welcome
to
the
node.js
next
10
meeting
for
january
16
2022.
A
We
will
go
and
look
at
our
agenda,
although
there's
not
a
lot
on
our
agenda
this
week,
so
we'll
probably
spend
most
of
the
time
looking
at
the
mini
summit
that
we
had
a
few
weeks
ago
before
I
get
started,
here's
the
link,
I'm
just
going
to
post
it
to
there
everybody
if
people
could
add
in
their
themselves
into
the
present
list,
so
that
we
we
know
who's.
Who
is
here
going
to
add
myself?
A
That
would
be
great
before
we
get
started.
Are
there
any
announcements
that
people
would
like
to
share.
A
If
not,
I
think
the
only
thing
I'll
mention
is
that
if
people
haven't
seen
the
announcement
that
the
trademark
for
the
node.js
for
node.js
itself
was
transferred
over
to
the
foundation
this
this
week,
that
happened
that's
great.
Otherwise
we
can
move
on
to
the
other
agenda
items.
A
The
first
one
was
the
provide
a
pre-built,
node.js,
node.js
images
or
cache.
You
know,
tierney
mentioned
that
you
know.
There's
no
major,
no
major
updates
this
week
still
working
to
basically
get
you
know,
pre-built
docker
images
that
we
can
just
pull
down
and
use
to
build
node
as
one
of
the
things
to
enable
easier
contributions,
but
no
major
update
on
on
that
today.
This
time
the
other
one
we
had
on
the
agenda
is
the
technical,
deep
dive,
and
actually
that's
that.
I
think
we
should
just
switch
over
to
the
summit.
A
So
there
were
two
major
parts:
just
you
know
to
catch
people
up
who
may
not
have
been
able
to
make
it
for
the
whole
part.
The
first
part
was
on
modern
http,
and
you
know
we
sort
of
we
workshop
in
that
that
session,
what
we
thought:
modern,
http,
what
the
key
things
were
for
the
project
to
work
on,
and
we
actually
landed
that.
So
let
me
find
that
as
well
I'll
put
in
the
link.
A
So
the
plan
for
modern
http
was
captured
in
that
high-level
strategy
document.
Here
I
might
as
well
just
share
it
so
that
it's
a
little
easier
for
people
to
see.
A
A
You
know
some
of
the
key
things
we,
the
current
apis,
like
http,
1
and
http2
are
very
specific
to
the
protocol.
We
really
want
our
to
move
towards
apis
which
are
protocol
independent,
so
that
they
can
support
any
one
of
the
http
protocols.
A
Similarly,
like
they
shouldn't
really
be
tied
to
the
transports
like
tcp
or
quick,
they
should
be
able
to
support
the
different
transport
protocols.
You
know
we
want
good
default
defaults.
We
want
the
client
and
server
apis
to
be
to
be
consistent,
so
that
you
know
if
you're
using
one
the
other
ones
look
familiar.
A
You
should
be
able
to
do
common
things
like
piping
from
the
client
api
to
the
server
apis,
and
we
agreed
that
really.
We
need
multiple
apis,
probably
like
you
know
something
higher
level
that
that,
if
you're
just
doing
some
simpler
things
you
can
use
and
then
some
lower
level
ones
that
give
you
more
control.
So
if
you're
really
trying
to
tune
performance,
you
have
those
extra
levers
and
knobs
to
be
able
to
do
that.
A
We
also
came
to
the
conclusion
that,
unfortunately,
our
existing
apis
don't
really
meet
those.
So
you
know
the
they're
widely
used.
We
don't
plan
to
deprecate
them,
but
they're
not
going
to
be
the
focus
of
future
enhancements.
We're
not
going
to
look
to
like
improve
them
to
add
other
http
versions
or
to
improve
the
performance
they're
kind
of
they're
there
they're
widely
used,
but
they'll
probably
just
stay
there.
A
We
we
also
captured
that,
like
in
terms
of
http,
you
know
http
2
is
kind
of
in
maintenance
mode
like
it's
got
some
nice
niche
usage,
but
it's
not
really
where
we
see
there's
going
to
be
a
major
uptake.
Http
3
is
the
the
more
interesting
one
for
future
uptake
and
http.
A
1
is
a
fable
stable
protocol,
but
there's
still
value
in
innovating
there
in
terms
of
say,
performance
or
better
apis
and
that
kind
of
stuff,
and
so
we
agreed,
we
should
build
out
two
apis,
two
new
server
apis,
two
new
client
apis
in
line
with
that
strategy,
transport
level.
Things
like
socket
level
apis
aren't
really
tied
to
the
http
strategy.
We
should
support
different,
socket
level
protocols,
but
that
should
sort
of
be
the
lower
level
and
one
api
should
support
whatever
transport
you
need
to
use
so
specifically
for
client
apis.
A
We
agreed
that
we
should
do
a
fetch
based
api
on
top
on
top
of
indici,
which
actually
has
already
landed
in
experimental,
which
is
great,
so
this
discussion
kind
of
unlocked
that
and
then
the
lower
lower
level
api.
A
You
know
I
we
talked
about
was
exposing
a
subset
of
indici,
but
we
weren't
ready
to
just
pull
in
in
dc
yet
so
that
that's
sort
of
the
next
core
area
of
like
how
do
we
once
once
fetch
is
in
and
we're
comfortable
with
that,
then,
like
the
next
step,
is
probably
look
at
that
lower
level
api
and
figure
out
like
what
is
a
good
subset
of
that
to
to
offer
that
or
maybe
something
different,
but
to
look
at
it
as
a
starting
point
for
what
that
lower
level
api
in
the
client
would
be,
and
then
on
the
server
side,
we
had
much
less
definition,
but
we
were
thinking.
A
We
would
align
it
with
the
client
side
api,
so
you
know
once
we
get
through
those
and
then
in
the
rest
of
this
talk,
I
just
tried
to
capture
some
information
that
we
have
about
the
existing
apis
and
it's
the
place
where,
when
we
add
like
we
should
probably
add
in
a
section
now
on
fetch
to
talk
about
where
that
is
and
provide
whatever
guidance.
We
can
on
that
front.
So.
A
In
terms
of
like
next
steps
for
the
next
10
team,
I
think
you
know
our
our
our
effort
is
around
trying
to
identify
and
capture
what
we
should
do.
So
I
think
for
the
modern
http
we
might
have
a
pretty
good
handle
on
that.
I
don't
know
what
other
people
think
in
terms
of
you
know
having
having
landed
this
document
for
the
modern
http.
Is
there
anything
else
that
we
should
be?
You
know
in
our
team
be
prioritizing
to
do
at
this
point.
A
Phew,
I
didn't
know
how
long
I
was
talking
with
nobody,
everybody
just
blankly
staring.
I
guess
my
best
just
to
repeat
my
last.
My
last
sort
of
question
was
like
at
this
point.
You
know:
having
landed
this,
this
maintaining
http
with
our
strategy.
A
Is
there
anything
else?
The
next
10
teams
should
prioritize
at
this
point
on
the
modern
http
front,
or
do
we
think
this
is
you
know
this
is
a
a
good
like
we
sort
of
got
this
one
in
hand
and
and
there's
a
strategy,
and
maybe
once
a
few
more
things
like
the
we
work
through
the
we've
got,
you
know,
fetch
there's
been
progress
and
once
there's
level
at
low
level
on
the
client
apis.
We
might
you
know
when
we
do
a
revision,
we
can
come
back
and
say
like.
Are
we
making
progress
on?
C
Yeah,
my
gut
is
like
it
it's
now
on
the
radar
of
a
lot
of
the
collaborators,
the
tsc
and
also
the
indici
team,
pushing
things
forward
so
may
yet,
maybe
like
in
a
three
months
time
kind
of
thing
we
should
just
revisit
and
see
if
there's
any
progress,
but
in
terms
of
next
10
driving
it.
I
don't.
I
don't
see
the
need
right
now.
B
Maybe
more
a
question
I
don't
know.
I
believe
this
might
have
been
discussed
already,
but
in
terms
of
process
like
what
are
we
doing
like
actively
doing
to
make
sure
that
the
people
working
on
only
cpu
moving
forward
like
they
just
they
have
in
top
of
their
minds
that
if
discussions
come
up
like
they
can
always
revisit
the
discussions
we
already
had
in
the
in
the
next
10
meetings
like
yeah.
How
are
we
kind
of
planning
for
that?
Moving
forward.
A
I
think
you
mean
like
having
another
session
or
just
like,
obviously
the
people
who
are
progressing
it
can
modify
or
change
the
strategy
at
any
time.
Might
you
know
the
way
I'd
see
what
go
ahead,
it's
more
of
a
guidance
right
exactly
like
for
me,
it's
good
to
write
down
what
we
think
our
current
state
is.
So,
ideally,
if
you
know
if
people
are
working
on
it
and
they're
like
well
wait
a
second.
This
doesn't
make
sense
anymore,
prn
the
changes
into
this
doc.
A
B
Yeah,
I
guess
my
suggestion
would
be
like
let's
just
make
sure
that
the
contributors
like
working
on
this
yeah
they
have
on
top
of
their
mind.
They
can
always
come
and
like
revisit
or
just
point
to
this
document.
If,
but
whenever
discussions
came
up
right,
they
can
say.
Oh
you
know
I
discuss
this.
You
can
look
at
us
here
right.
A
B
A
Okay,
so
yeah,
so
let's
I'm
gonna
go
back
to
the
notes.
So
fine
from
rmst.
A
A
Okay,
so
that's
kind
of
where
I
think
we
are
now
it's
it's
we're
better
defined
than
some
of
the
others,
so
agreement
that,
with
the
doc
capturing
a
strategy,
we
are
probably.
A
A
A
To
know
they
can
change
makes
it,
you
know,
makes
make
additions
anything
else
in
that
list
like
we
want
them
to
know
they
exist.
We
want
them
to
know
they
can
change
them.
You
know
make
additions
to
them
any
other
things
that
we
want
them
to
make
sure
that
they
know.
B
C
There's
also
something
around.
Sometimes
some
of
these
documents
are
more
leaning
towards
certain
teams
and
working
groups
than
others.
So
is
there
you
know
the
indicia
group.
Should
it
point
to
this
stock
as
well?
I
I
don't
know,
I
don't
know
if
it
should
just
be
referenced
from
the
group
so
that
the
smaller
groups
are
aware
of
it.
A
C
C
One
kind
of
tangible
thing
that
we
could
probably
do
to
make
collaborators
aware
would
be
any
on
boarding
dock
and
you
work
through
the
onboarding
process.
Just
to
say,
hey,
we
have
a
bunch
of
guides
covering
you
know
how
we
contribute
to
these
specific
areas
read
through
any
of
them.
You
know
if
you're
interested
or
need
to
bear
it
in
mind
when
you're
contributing
in
one
of
these
areas.
A
A
A
So
I
think
pr
in
references,
that's
like
a
concrete
thing
we
could
do.
Are
there
any
other
concrete
things
like
that
in
terms
of
next
actions
that
I
guess
we
could
look
to
look
at
in
dt
docs,
where
I'm
going
to
see?
If
I
can
spell
that
right.
A
C
Yeah,
I
don't
know
if
it
works
same
way
as
we
have
previously,
but
if
the
collaborator
summit
does
go
ahead-
and
I
know
at
the
start
of
the
day,
there's
normally
like
an
introduction
type
thing.
I
think
addressing
everyone
there
about.
This
effort
probably
makes
sense,
rather
than
making
it
a
breakout.
I
I
just
think
it's
another
opportunity
to
get
in
front
of
everyone.
Who's,
a
contributor
or
collaborator.
A
C
Yeah
I
mean
it
might
be
worthwhile
having
breakouts,
but
actually
that
might
be
something
to
consider.
Maybe
each
topic
could
be
a
breakout
type
session
or
something
but.
A
Okay,
so
much
been
I've.
I've
tried
to
promote
jaw
a
few
times,
but,
oh
so
jean
said
hello,
there
oh
see,
oh,
I
think
it
finally
finally
worked
yeah.
No,
so
that
that's
definitely
a
good
one.
I
think
you're
right
that,
like
one
of
those
sessions
up
front
just
to
make
sure
everybody
knows,
this
is
happening.
What
the
docs
are,
that
they
feel
you
know
they're
they're,
they're
not
meant
to
be
the
they're
meant
to
be.
This
is
what
we've
agreed
now
and
so
they're.
A
A
C
I
kind
of
think
the
best
way
to
approach
external
folks
are
3d
individual
topics
and
to
bring
them
in
for
the
individual
topics,
and
I
think
we
did
a
good
job
of
that
in
the
previous
couple
of
summits.
A
Okay
sounds
good,
I
just
wonder
like
say
for
the
http
one:
does
it
make
sense
at
all
to
say,
like
somebody
write,
a
blog
post
that
we
would
publish
under
the
note
account
saying
you
know
we
had
the
summit,
here's
the
strategy
that
we
came
up
with
in
terms
of
http
or
or
is
it
was
it?
We've
already
got
the
people
who
are
interested
involved,
and
you
know
that's.
C
A
Okay,
well,
I
think
we
have
some
good
next
actions
there
like
we
can.
You
know,
I
don't
know
if
somebody
wants
to
volunteer
to
pr
and
the
references
to
the
collaborator
onboarding
docs
or
we
can
just
leave
that
as
a
I
might
create
some
issues
to
do
that
in
the
repo
and
whoever
picks
them
up
can
pick
them
up.
A
So
maybe
I'll
take
the
action
to
add
these
as
issues
unless
somebody
wants
to
volunteer
to
pick
them
up,
in
which
case
I
might
like
create
the
issue
too.
C
B
A
Okay,
so
the
I
think
we've
sort
of
recapped
on
the
modern
http.
Actually
I
just
want
to
fix
my
format
in
here.
A
There
was
a
very
good
discussion
on
some
of
the
things
that
we
thought
were
key
elements,
and
so
I
should
still
be
able
to
see
my
screen
with,
and
I
think
I
have
a
summary
here
so
summary
of
what
we
agreed
you
know
was
to
focus
on
the
api
doc
documentation
versus
anything
else.
A
A
Those
are
not
necessarily,
you
know
something
that
we
need
to
make.
There's
lots
of
places
that
those
could
be
those
don't
necessarily
need
to
be
in
the
node
project
itself.
We
might
syndicate
those
kind
of
things
like
have
references
to
good
good
ones,
but
it's
unlikely
that
we're
going
to
be
able
to
like
maintain
a
big
set
of
those
there
was
mention.
We
have
some
good
content,
so
we
might
keep
some
some
content
that
we
already
have.
A
But
you
know,
that's
not
necessarily
a
focus
when
we
think
you
know
it
wasn't
going
to
be
a
focus
when
we
think
about
documentation.
It's
really
like
what
can
we
do
on
the
api
front
and
some
of
the
forward-facing
documentation
like
the
release
documentation,
so
people
know
how
to
get
releases
where
they
are
all
that
kind
of
stuff.
A
There
was
some
agreement
in
terms
of
like
the
api
docs.
What
what
is
in
scope-
and
really
you
know
we
agreed-
we
don't
need
to
redocument
javascript,
there's,
there's
good
documentation
for
there,
so
it
should
really
be
the
node
additions
on
top-
and
you
know
mostly
the
specs
for
the
api
versus
the
api
versus
anything
else.
A
The
key
things
that
we'd
agreed
with
we
thought
we
should
work
on
was
well
one.
We
should
be
able,
we
should
say
well
what
is
our
strategy
so
like
again
back
to
this,
you
know:
what
is
our
focus?
What
are
we
focusing
on
so
find
somewhere
where
we
can
capture
that
says
you
know
yes,
docs
are
important,
but
what
does
that
mean?
It
means
that
we're
going
to
be
it's
important
to
have
good
api
docs.
A
Part
of
that
is
like
we
have
some
metadata
in
the
documentation,
but
I
don't
think
we,
the
consensus
there
was
like
we
don't
have
that
well
documented,
so
we
want
to
say
well
what
is
that
metadata?
Why
do
we
have
the
data
that
metadata?
What
what
workflows
does
it
support
so
that,
as
we
work
on
the
docs,
we
know
why
it's
there
and
we
can
use
that
to
drive.
A
You
know
how
we
maintain
it
consistency
across
packages.
I
see
I
copied
this
document
metadata
twice
but
like
again
making
sure
that
one
of
the
the
key
things
was
like,
so
that
when
you
look
at
the
different
sections,
they're
they're,
consistent
and
then
the
other
gap
that
that
was
discussed
was
that,
like
not
every
api,
has
an
example
and
that's
that's.
A
One
of
the
key
things
is
to
have
the
example
in
line,
so
you
can
see
how
the
api
is
used
in
addition
to
just
having
to
find
the
methods
and
the
parameters
and
stuff,
it
was
also
discussed
as
important,
perhaps
maybe
in
some
cases,
more
complete
explanation
for
the
methods
and
some
better
links
between
concepts.
So
we
you
know
one
of
the
things
discussed
is
you
can
you
know
you
may
be
trying
to
use
something?
That's
exposed
through
one
api,
but
it's
actually
only
documented.
A
You
know,
example
that
every
method
has
an
example
examples
in
line.
How
do
we
validate
that?
You
know:
we've
talked
about
how
we
could
validate
that
they're
there,
so
that
we
know
whether
we're
meeting
those
goals
or
not,
so
that
that's
was
sort
of
a
high
level.
Disc
recap
of
the
discussion,
and
I
guess
the
question
the
thing
we
could
talk
about
here
is
like
okay.
What
can
we
do
to
sort
of
kick
off
those
next
steps.
C
Yeah,
my
gut
is
the
document
metadata
and
white
supports
could
just
be
in
like
a
to-do
issue
like
for
someone
to
pick
up
the
ad
examples,
one,
I
think,
probably
warrants
an
issue.
I
don't
know
if
in
notepad
or
something
to
say,
hey
the
next
10
group,
which
is
a
small
group
of
people,
think
it
would
be
valuable
to
add.
You
know
an
example
to
every
api
in
the
documentation.
C
I
think
that
that
needs
to
be
a
discussion
and
having
that
very
specific
discussion
of
should
every
api
have
an
example
rather
than
wrapping
it
into
a
whole
overhaul
of
like
the
style
of
our
docs.
I
think
that's
a
very
explicit
discussion
that
can
be
had
and
if
we
get
a
solution
to
it
and
people
say
yes,
okay,
then
work
will
naturally,
you
know
start
to
happen
in
that
area
and
people
will
start
peeing.
I
ring
all
the
examples
in.
A
Right,
I
think
what
would
be
good
to
drive
that
discussion,
because
at
least
my
experience
is
prs
drive
engagement
is
like
if
we
can
figure
out
where
we
would
peer
that
in
and
there
be
a
pr
open
to
document
that,
like
you
know,
and
we
can
get
consensus
like
either
people
will
be
like
yeah.
We
should
do
that
or
if
the
answer
is
no,
then
it
won't
land,
but
if
it
does
land,
then
there's
like
here's
the
place
where
we've
captured,
that
that
is
our
strategy.
C
Yeah,
I
suppose
my
suggestion
is
like
we
approach
it
from
a
small
addition
to
the
docs
yeah
question,
rather
than
you
know,
try
and
rewrite
everything
at
the
same
point
in
time
I.
A
Agreed
agreed,
like
I
think
of
you,
know
the
smallest.
You
know
if
we
let's
look
at
our
docs
right,
so
we've
now
got
these
contributing
docs.
Do
we
have
a
dock
that
we
would
put?
That
into
is
the
starting
like.
That
would
be
the
simplest
starting
point
right.
C
C
A
There
were
some
things
we
wanted
to
do
along
those
lines
and
tierney
had
a
pr
which
actually,
I
think,
did
of
some
of
the
things
you
you
mentioned,
but
I
also
know
rich
was
talking
to
him
about
like
trying
to
get
that
into
smaller
pieces.
A
A
Because
yeah,
I
think
I
think
you're
the
the
larger
refactor
makes
sense,
but
maybe
just
getting
it
in
there
like.
So
then
it's
like
an
agreed
thing.
We
could
then
say:
well,
okay,
you
know
if
people
want
to
contribute.
This
is
one
of
the
things
you
can
do
is
to
add
examples
right
and
and
anyway
it
would
drive
the
yes.
We
agree
with
that
or
not
kind
of
thing.
A
A
So
what
I'll
do
is
I'll
create
an
issue
in
the
next
10
to
unless
somebody
else
wants
to
volunteer
that
to
track
that
work,
because
I
think
that
could
be
done
in
like
it
doesn't
need
to
be
a
big
bang.
It
could
be
like
hey.
Somebody
has
a
little
bit
of
time,
they're
going
to
look
at
the
added
metadata
and
they
could.
We
could
add
in
some
documentation
of
what
that
is
right,
and
then
you
know
in
a
separate
pr.
We
could
pull
in
documentation
of
the
next
bit
of
of
metadata
and
so
forth.
A
Okay,
I
think
those
are
two
concrete
like
that.
Along
with,
I
know
the
you
know,
the
fact
I
know
tierney
is
looking
at
a
little
bit
and
hopefully
we'll
we'll
do
some
more
sort
of
on
the
main
documentation
page.
I
think
the
idea
was
to
pull
in
maybe
in
a
little
bit
more
incremental
manner,
some
of
the
stuff
that
came
out
of
the
the
the
the
work
on
types.
A
A
And
at
least
start
the
discussion.
So
that's
a
that's
good,
any
other
things
like
on
that
documentation
front
that
we
think
we
should
think
about
or
plan
for
in
terms
of
the
the.
A
A
This
one
isn't
on
the
agenda,
but
I
propose
we
put
on
put
this
on
the
agenda.
Just
to
you
know,
have
it
on
the
list
of
things
we
talk
about.
Does
that
make
sense
bradley
is
bradley
still
with
us
or
jean
no
yeah.
It
makes
sense
for
me,
okay,
so
I'm
going
to
add
that
to
the
so,
if
we
think
about
what
we're
going
to
talk
about
next
time,
we'll
have
that
on
the
agenda.
E
That
no,
not
really,
I
didn't,
really
look
on
it
since
last
time,
so,
okay,
so
yeah,
so
we
maybe
can
you
know
next
time,
let's
plan
to
have
some.
B
A
C
One
thing
that's
kind
of
my
head:
I
wonder
if
it
makes
sense
to
make
the
next
10
effort
a
strategic
initiative.
I
know
that
kind
of
is
a
bit
recursive,
but
but
that
would
force
someone
to
champion
it
and
someone
to
give
updates
that
did
here
see
meeting,
which
I
think
would
you
know
I've
seen
before
that
people
aren't
really
aware
of
what's
happening
in
the
next
10
group,
and
I
think
at
least
the
tsc
should
be
made
aware.
A
That's
a
good
idea,
and
it
does
if
people
watch
say
the
tsc
meetings,
it's
another
way
to
kind
of
get
the
message
up
there
yeah,
I
think
you
know
I'd,
be
I'd,
be
happy
to
give
updates
as
a
strategic
initiative
or
if
you
would
want,
if
you
wanted
to
volunteer
to
do
that,
I
think
we
could.
That
makes
a
lot
of
sense
to
me.
A
A
I'm
thinking
so,
then
I
think
the
so
we've
got
some
next
steps
for
sure
in
terms
of
I'm
going
to
create
a
couple
issues
which
I'll
I'll
tag
in
the
other
thing.
I'm
thinking,
then,
is
we
might
want
to
think
about
like
identify
the
next
deep
dive
like
which
technical
priorities
to
to
deep
dive
into
next.
A
A
A
Yeah
we
can
talk
about
timing
and
so
I'll
put
in
that
here.
So
what
topics
when
and
so,
if
everybody
can
kind
of
think
about
that
between
now
and
then
we
can
probably
have
a
good
discussion
and
close
on
that,
which
would
be
a
good
idea.
D
Yes,
if
you
have
the
url
of
the,
I
think
we
had
a
p
appear
with,
with
a
result
of
the
of
the
forms
we
send
to
two
people.
It
could
be
great
to
to
check
on
that
also,
which
was
it
the
I
I
don't
remember.
I
I'm
trying
to
find
it,
but
I
I
don't
yeah.
A
D
No,
I
don't
think
we'll
do
that,
but
we
add
up.
We
had
the
priorities
based
on
the
results
done
by
the
what
what.
E
A
C
A
Haven't
we
haven't
discussed
that
we've
done,
I
think
we
we
had
one
which
was
sort
of
just
a
more
general
one,
and
then
we've
done
two
and
I
think
well,
we
can
actually
here
we
can
go
and
take
a
look
because
they
are
in
the
meetings.
So
there
is
a
we
did
november
then
january
for
the
actual
deep
dives.
C
C
This
quarterly
we
might
squeeze
one
in
before
that
as
well
yeah,
it's
worth
thinking
about
which
ones
would
make
sense
to
do
sooner
or
later
versus
which
ones
make
more
sense
to
be
in
person.
A
Right
to
plan
the
next
two
with
with
one
being
open,
js,
so
yeah.
So
I
think
what
you're
suggesting
what
I
wrote
down.
There
is
like
it's
good
to
plan
the
next
two
one
of
those
two
being
at
openjs
world,
the
other
one,
either
being
before
or
after.
But
like
let's
plan
those
two
in
the
context
of
we've
got
that
opportunity
and
which
ones
make
sense
to
be
there
versus
not.
C
A
Okay
yeah,
I
know
those
are
good
thoughts
and
yeah,
I'm
kind
of
just
we
can
think
about
it
between
now
and
then.
But
I
I'm
thinking
we
can
maybe
squeeze
another
one
in
there
and
because
it's
five
months
away,
no,
maybe
less
so
four
but
yeah
we
might.
We
might
squeeze
another
one
in
and
then
but
yeah
it's
good
to
look
at
we'll.
We
can.
We
can
look
at
the
as
as
the
next
two
is
kind
of
like.
Let's
look
at
them
together
versus
just
look
at
the
another.
One
is
definitely
good.
A
Okay,
I
think
just
looking
at
sort
of
making
it
so
that
the
next
agenda
shows
a
little
bit
better.
What
we're
gonna
talk
about.
A
Still
may
not
be
the
best
time,
but
it's
hard
to
find
time
times
that
work.
A
A
I
guess
I'll
take
silence
as
as
a
yes
and
thanks
thanks
for
everybody
perfect
for
that
participating.
I
think
we
had
a
good
discussion.
We've
got
some
concrete
actions
to
move
forward
with
and
we'll
see
everybody
next
time.