►
From YouTube: 2021-08-05-Next-10 - Mini Summit
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
next
10
mini
summit,
hi
mateo,
he
was
just
waving.
I
guess
everybody
could
see
that
beth
is
here
with
us.
Well,
I
guess
beth,
that's
the!
If
you
I
don't
know
if
you
can,
but
if
you
turned
on
your
camera
and
blocked
it,
you
would
show
up
better
in
the
recording.
We
could
see
when
you
talk
just,
but
if
not
possible,
just
thought
I'd
mention
it
anyway.
A
The
going
to
quickly
share
my
screen
with
the
agenda.
So
where
did
I
put.
A
A
A
Okay,
so
this
is
the
agenda
that
I
put
together
a
quick
review
of
just
you
know
what
we've,
what
we've
done
today,
we
can
do
that
as
quickly
or
as
slowly.
It
slowly
makes
sense
for
people
in
terms
of
you
know
how
much
they've
kept
on
track
of
that
part,
but
again
meant
to
keep
that
short,
then
get
into
it
says
my
screen
sharing
is
paused.
Does
that
make
sense.
A
B
A
Okay,
so
this
was
a
quick
agenda
put
together,
so
quick
review
the
work
to
date,
trying
to
keep
that
short
then
get
into
looking
at
the
technical
priorities.
We
have
some
data
where
you
know
the
team
had
gotten
together,
brainstormed
that
we
got
some
some
some
things
from
the
collaborators
and
the
goal
would
be
to
convert
that
into
you
know
what
we
want
to
write
down
as
priorities
for
the
project.
A
The
next
one
is
the
next
10
years
for
collaborators.
So
that's
talking
about
you
know
not
necessarily
the
technical
priorities,
but
what
we
think
it
should
look
like
in
terms
of
you
know
the
collaboration,
experience,
governance,
that
kind
of
stuff,
and
then
finally,
you
know
use
the
last
bit
to
try
and
make
sure
that
we
have.
You
know
some
concrete
outcomes.
A
Some
next
actions-
and
you
know-
we've
captured,
say
our
our
draft
of
what
we
would
actually
pr
in
as
some
of
the
priorities
goals
for
each
section
are
to
come
up
with
a
set
of
notes
and
a
list
list
of
key
next
steps.
A
A
So,
just
you
know
in
terms
of
what
we've
done
so
far
is
we
put
together
this
list
of
constituencies?
So
this
is
you
know
what
we
put
what
we
have
come
together
and
documented
as
the
the
different
groups
that
you
know,
have
a
stake
or
have
requirements
or
have
needs
in
terms
of
of
node.
A
You
know
so,
including
the
direct
end
users,
people
who
operate
applications,
application
developers,
the
library
package,
authors,
of
course,
the
contributors
to
core
the
organizations
who
invest
in
node,
and
you
know
so,
for
example,
organizations
who
bet
on
node
or
developers
who
you
know
groups
who
actually
you
know,
say
we're
going
to
standardize
on
using
node
and
so
forth.
They
have
it.
They
have
a
stake
education,
so
you
know
education,
so
people
like
teachers
and
students
so
sort
of
the
ecosystem
around
helping
people
learn.
A
You
know
we
want
to
make
sure
that
we
meet
their
needs
in
terms
of
helping
people
learn
node,
you
know
and
including
people
being
able
to
show
that
they've
got
certain
qualifications
like
certification
and
then
the
last
one
was
the
security
practitioner.
So
the
people
who
basically
handle
the
life
cycle
of
security
issues,
you
know
we
want
to
make
sure
that
we
cover
their
their
needs
as
well.
A
So
we've
already
worked
on
that.
It's
just
going
through
this
quickly
because
sort
of
like
we
wanted.
We
should
look
through
keep
the
keep
the
constituencies
and
what
they
need
through.
You
know
as
what
we
consider
or
go
back
to
when
we're
discussing
the
the
priorities.
A
You
know
how.
How
are
we
needing
meeting
or
not
meeting
the
needs
of
those
constituencies,
as
we've
understand,
understood
and
documented
them
so
based
on
those
constituencies,
we
then
went
through
and
looked
at
what
all
their
needs
were,
so
just
as
a
quick
walk
through,
so
that
we
have
them
fresh
in
our
mind,
as
we
think
through
the
the
other
sections
you
know,
a
good
understanding
in
of
the
direction
of
the
project
is
one
of
them
and
in
fact
you
know.
Maybe
this
is
this.
A
Next
10
work
is
part
of
what
we're
doing
to
help
support
that
the
ability
to
affect
the
direction
of
the
project
consumable
apis
and
docs,
predictable,
stable
releases,
innovation,
consumable
pace,
easy
installation,
easy
issue,
reporting
resolution
collaboration,
broad
deployment
platform,
support,
broad,
desktop,
desktop
platform,
support,
consistent
intuitive
error,
handling,
runtime
diagnostic
tooling
development
time,
diagnostic,
tooling,
relevant
apis
and
core
module
dependency
info
and
management.
So
this
is,
you
know.
A
Obviously,
the
ecosystem
of
modules
is
a
key
part
of
any
node
application,
ways
to
fund
their
work
for
some
of
the
constituencies
ability
to
assess
the
impact
of
changes
that
they
make.
A
You
know
we
want
good
resource
usage
and
performance,
so
we
make
good.
You
know
we're
basically
using
our
resources
effectively
good
security
and
cv
practices,
better
cv
management
in
the
ecosystem,
so
this
isn't
necessarily
within
node
core
itself.
But
what
can
node
do
to
help
support?
A
You
know
good
cv,
management
and,
and
the
ability
to
to
sort
of
go
to
do
a
good
job
wall
main
you
know,
keeping
the
the
work
reasonable
and
so
forth,
good
ci
infrastructure
and
experience
in
the
project,
support
collaboration,
environment
and
collaboration
environment.
That's
probably
related,
you
know
to
that
section
section
in
terms
of
the
collaboration
approach
and
and
the
basically
what
we
want.
Our
are
the
key
things
to
that
are
important
to
make
sure
that
we
are
successful.
A
You
move
forward
in
terms
of
contributing
better
ways
to
build
concessions
in
the
project,
easy
contribution,
workflow
ability
to
embed
in
bundle
node.js
the
runtime
itself,
a
well
maintained
and
secure
standard
library
and
assets
that
show
node.js
is
a
good
choice.
So
these
aren't
all
things
that
necessarily
are
in
node
core
itself
today
or
need
to
be
in
node
core,
but
they're
the
needs.
The
key
needs
that
we've
we've
called
out.
A
We
did
do
a
survey
to
sort
of
you
know
refine
these,
and
so
I'm
just
trying
to
go
back
there.
I
guess
I'm
going
to
have
to
go
back
here,
just
as
a
reminder
for
people
if
you
want
to
go
and
take
a
look
at
the
survey
data
it's
available
in
the
repository.
A
You
know
we
have
the
results
in
a
pdf
with
a
presentation,
and
you
know
we
use
that
to
confirm
the
constituencies
and
the
needs
that
we
brainstormed
and
put
together
to
make
sure
you
know
we
had
missed
any.
In
fact,
we
pr
some
additional
ones
in
based
on
the
survey
results.
So
I
just
wanted
to
mention
that,
as
if
people
are
interested,
they
can
go.
Look
at
the
survey
results
because
they're
in
the
repo.
A
So
that
was
all
I'd
planned
for
the
quick
walk
through
of
the
the
constituency
needs
and
so
forth.
You
know
before
we
move
forward.
I
don't
know
if
there's
any
questions
here,
I
should
promote.
A
D
A
I
I
think
that
could
be
in
one
of
our
follow-ups.
We,
we
don't
have
a
current
plan.
One
one
thing
we
do
plan
to
do
is
to
put
together
a
sort
of
a
follow-up
in
terms
of
you
know
what
we
learned
from
the
survey,
so
I
haven't,
haven't
quite
got
to
that.
But
that's
one
thing
we
did
want
to
follow
up.
You
know
having
people
having
participated,
we
wanted
to
make
sure
that
we
communicated
back
what
the
value
that
they
provided
and
how
it
helped
us.
A
A
A
If
not,
let's,
I
don't
think
I'm
not
thinking.
We
need
a
break
between
this
this
one
and
the
next
next
one.
Is
that
fair
for
everybody
or.
A
A
This
one
is
a
different
one.
Yes,
I
the
the
deck
I
yeah
the
deck
I
did
in
my
own
account
and
I
I
will
have
to
give
permissions.
The
the
rest
of
the
docs
I
actually
just
put
is
the
place
where
the
regular
issues
are
created,
so
you
should
be
able
to
get
access
to
that
one
directly.
Let
me
know
if
that's
not
the
case
and
beth.
Are
you
trying
to
promote
rick
and
sergey.
A
E
A
Want
to
make
sure
we
get
everybody
in
who
who
wants
to
get
in
cool
so
beth,
I
don't
know,
maybe
you
can
message
sergey
while
we
we
move
on
and
see
if
you
can
figure
out
how
to
get
him
in
unless
there's
or
maybe
we
should
just
take
a
minute
or
two
to
do
that,
because
I
see
now
jean's
joining
as
well.
A
A
G
A
Just
okay:
well,
I
think
sergey's
dropped
off.
Maybe
we'll
see
him
back.
It's
beth!
You
can
keep
an
eye
out
for
for
him
to
come
back.
That
would
be
great,
so
I'd
say:
let's
move
on
to
the
next
section,
which
is
to
look
at
the
the
technical
priorities
which
we'd
put
together
and
sort
of
work
on
that
side
of
things.
So
let
me
go
over
to
there.
A
A
A
Oops
did
I
get
that
link
wrong?
Maybe
I
did
sorry
going
back
to
cut
and
paste
the
right.
A
A
A
Okay,
so
this
was,
as
you
can
see,
this
is
the
the
list
that
we
had
and
I
I
I
propose
we
sort
of
go
through
the
top
ranked
ones
discuss
them
and
as
we
do
that
build
a
list
which
we
think
is
sort
of
an
ordered
list
of
what
we
think
should
be
on
our
top
technical
priorities,
and
you
know
at
the
end.
A
Hopefully
we
come
up
with
something
I
think
we
you
know
we
need
to
pick
a
smaller
set
like
you
know,
whether
it's
five
or
ten
or
I
don't
know
some
more
constrained
number
that
we
say
like
for
this
year.
We
think
these
are
the
the
key
things
I
don't
know
what
people
think
of
that
approach.
Does
that
make
sense
to
people.
F
D
C
It's
it's
definitely
one
of
mine.
I
don't
know
if
it's
one
of
like
been
working
on
this
for
a
few
years
now,
right,
it's
literally
a
long
time
coming
by
the
way
we
are
landing,
our,
hopefully,
a
fetch,
compliant
aspect,
compliant
fetch
implementation
or
as
compliant
as
in
in.
A
Fetch
so
this
is
where
I
guess
we
we
need
to
decide.
Do
we
want
to
sort
of
try
and
go
a
little
bit
deeper
in
in
these
or
do
we
want
to
try
and
go
through
the
whole
list
figure
out
the
top.
You
know
five
or
six,
ten,
whatever
it
is
and
then
go
more
in
depth
in
those
in
terms
of
like
what
we
should
be
planning
or
yeah.
Do
we
do?
We
want
to
go
shallow
to
start
and
get
a
shorter
list
or
try
and
go
a
little
deeper.
A
C
A
C
B
B
B
C
H
C
B
Have
so,
in
particular,
the
fidelity
in
which
we
are
going
to
export
is
not
going
to
be
for
general
user
consumption.
It's
for
no.
C
D
C
To
to
make
to
have
node
core
run
dot
ts
files,
it
means
that
node
core
needs
to
ship
with
its
own
types.
So
we
we
have
a
con
for
end
users.
Okay,
I
don't
care
about
the
internal
ones,
I'm
talking
for
the
end
user.
Okay,
yes-
and
this
is
the
conundrum
that
we
are-
that
I'm
talking
about
that
there
was
a
discussion
already.
That
said,
no.
A
A
I
don't
think
we
know
the
right
answer
yet
like
we
would
need
work,
but
if
we
think
it's
important
to
satisfy,
you
know
the
the
types
for
end
users
for
the
the
success
like.
However,
they
come,
whether
it's
definitely
typed
or
whether
it's
node
core
or
you
know
whether
it's
something
we
do
in
node
core
to
help
definitely
type
to
their
work
more
easily.
That's
kind
of
a
separate
issue,
I
think
the.
How
can
be
separate
from
the
do
we
do.
We
agree.
A
B
A
C
C
C
B
Yes,
there's
a
reason
and
it's
kind
of
convoluted,
but
there
are
a
variety
of
apis
that
we
have
in
node
core,
which
are
not
able
to
be
typed
in
typescript
legitimately.
They
cannot
actually
be
typed
due
to
generic
constraints
and
other
things
like
that.
They
we
cannot
type
them.
You
have
to
just
write
out
a
definition
file
and
say
this
is
what
the
end
user
should
think.
It
is
what
percentage
of
those
it's
a
little
higher
than
you
might
think.
B
Just
due
to
some
coding
patterns,
things
with
polymorphic
returns
in
particular
are
not
good
for
typescript,
so
you
have
to
start
doing
function
overloads
for
those
jsdoc
can't
do
function,
overloads
and
so
now,
you're
at
now,
you're
at
needing
definition,
files
already
other
patterns
where
we
do
have
things
that
do
things
like
promisify,
that's
not
entirely
able
to
be
typed.
You
have
to
manually
type
out
the
conversions
for
a
bunch
of
stuff.
C
Already
done
manually,
so
all
the
work
has
really
been
done.
So
essentially
it's
been.
There
are
a
few
people
that
are
maintaining
those
tyres
tirelessly.
I
think
it's
two
or
three
very
clear
in
phenomenal
individuals
that
are
doing
this
for
the
community,
with
almost
no
recognition
they're,
not
even
part
of
the
node
core
collaborators,
to
make
it
even
more
which
they
should
be
to
some
extent,
because
they
have
contribute
they're,
clearly
contributing
to
the
success
of
node.js
and
making
node.js
more
usable
for
developers.
A
C
Yeah,
well
it's
one
of
those
discussions
that
it's
that
thread
that
I
pointed
to
it
includes
a
relevant
discussion
for
this.
It's
very
interesting
that,
like
this
typescript
like
so
this
is
why
it's
conflicting
for
me,
because
in
that
thread
it
seems
the
clear
opinion
of
everybody
was
no.
We
don't
want
to
do
that.
C
However,
it
seems
one
of
the
major
things
that
people
want
is
typescript,
so
either
you
want
it
or
you
don't
want
it
right
or
there
is
a
combination
of
people
that
you
know.
I
don't
know
how
many
responders
did
we
had
here.
These
are
these
are
the
core
collaborators?
C
A
Yeah,
I
think
it's
an
open
a
pr
to
do
what
right,
like.
I
don't
think
people
would
necessarily
have
said
like
there's
so
many
different
prs.
One
could
be
like
hey
we're
going
to
integrate
typescript
into
node
right.
You
know,
and
that's
totally
different
than
people
saying
we
think
type
having
good
types
for
end
users
is
is
important,
so
we
would.
A
Well
in
in
core
right,
but
I
I
don't
see
like
there's
still
many
different
options
like
it
would
be
like.
Well,
you
know
you
could
ship
it
with
core.
We
could
have
a
separate
repo
that
shipped
it
and
was
updated
for
some
reason
that
if
that
was
better
than
definitely
typed,
we
could
say
well.
Is
there
something
we
could
do
like
if
the
people
maintaining
definitely
type
thought
that
the
js
doc
would
help
in
some
way?
A
We
could
consider
that
I
kind
of
read
this
as
people
recognize
that
that
making
sure
we
end
up
with
good
types
for
end
users
somehow
is
important.
I
don't
think
it's
got
an
opinion
on
in-core
directly
or
not
or
whatever,
but
that
core
should
as
a
project.
We
should
should
pay
attention
to
this,
and
whatever
is
the
right
answer,
make
sure
it
happens.
C
A
A
Is
that
does
that
speak
up?
If
that
doesn't.
B
C
A
Okay,
I
will
move
on
to
the
next
one
then,
which,
from
the
numbers
I
see,
is
esm.
B
We're
in
better
shape
than
we
were
a
year
ago,
a
bunch
of
the
ecosystem
has
started
migrating
and
kind
of
understands.
The
problem,
rather
than
stating
node,
has
to
kind
of
just
break
specification.
B
B
People
do
want
a
few
features
that
they
consider
tied
to
esm
that
are
not
actually
tied
to
esm,
mocking,
so
basic
usability
for
esm
is
degraded
versus
common
js,
because
it's
more
static.
It's
more
constrained,
people
on
http
imports
and
stuff
like
that,
and
these
are
things
that
they
don't
really
associate
with
common
js
to
require
either
because
the
problems
don't
exist
or
because
the
feature
doesn't
make
sense
for
common
gas.
A
B
B
I
think
so
I
think
one
of
the
problems
we're
going
to
face-
and
one
thing
I
don't
want
to
focus
on-
is
loaders
as
much
as
people
want
to
the
javascript
standard
is
still
changing
some
nitty
gritty
stuff
about
how
things
like
caching
works
for
esm,
and
so
we
should
not
overload
the
idea
of
vsn
and
loaders
together,
because
loaders
just
cannot
be
stable
in
the
near
future.
B
C
So
the
problem
here
is
that
you
cannot
up
until
there
is
even
an
api
that
is
going
to
be
deprecated
and
removed.
Soon.
We
need
support
for
to
give
the
apm
vendors
a
loader
api.
B
So
they
don't
need
an
actual
loader
api.
There
is
various
ways
you
can
do
things
through
other
means
outside
of
loaders
they're,
also
experimental.
C
Okay,
let
me
let
me
reiterate
that
the
use
case
of
so
right
now,
most
signific
mid
size
to
big
users
of
node.js,
with
company
users
of
node.js
shipped
with
an
application
performance
monitoring
tool
and
right
now,
as
a
project.
Those
teams
cannot
move
to
esm
because
the
data
dog
elastic.
B
C
Again,
I
we
need
to
ship
something
that
it
provides
some
very
similar
constraints
of
where
we
had
with
asynchrops
that
essentially
it's
experimental,
but
we
are
not
going
to
massively
destroy
it
within
once
upon
a
release
goes
into
lts,
something
like
that.
C
A
C
A
The
fact
that
we
have
this
much
discussion
and
interest
in
discussing
it,
though
I
think,
goes
back
to
would
we
agree
that
esm
belongs
and
the
related
things
like
loaders
and
whatever
figuring
that
out,
which
we
can
spend
more
time
later
on
in
the
session
on
it.
It
makes
sense
to
be
in
that
number
three
point
in
the
list
so
far.
B
C
B
Mean
that's,
that's
the
whole
point
the
web
intentionally
doesn't
expose
the
exact
hooks
that
we
are
talking
about
right
now,
so
they
they
are
able
to
make
demands
that
do
break
our
expectations
on
the
hooks
and
they
do
make
those
demands.
C
B
B
C
That
that's
that's
kind
of
the
problem
of
that
we
are
in
in
here.
We
have
said
that
esm
was
stable
and
people
could
stop.
A
A
I
I
think,
there's
like
lots
of
things
we
need
to
figure
out,
but
I
think
it
seems
like
we
do
think.
It's
important.
C
Actually
out
docs,
like
from
my
point
of
view,
our
dots
are
great.
However,
they
don't
teach
you
how
to
use.
F
A
F
B
So
one
thing
that
I
do
like
on
mdn
is:
they
have
both
the
reference
stocks
kind
of
like
we
have,
but
the
reference
stocks
also
include
a
generally
a
practical
example,
not
just
how
to
use
an
api,
but
a
use
case
in
which
you
may
use
an
api,
and
then
they
have
entirely
separate
guides
on
how
to
do
things
like
using
the
canvas
api,
and
it
just
goes
through
like
making
a
small
toy
application
using
it
and
you
you
go
through
and
you
have
links
to
those
reference
docs,
but
you
see
how
they
work
together,
because
right
now,
every
api
is
effectively
documented
in
isolation,
not
how
you
use
them
together.
H
A
So
I
guess
like
so
far
it's
easy
as
we're
at
the
top
ones.
You
know
we're
only
at
number
four.
We
could
leave
this
at
number.
Four
and-
and
you
know,
look
at
the
others
and
we'll
we'll
have
to
like
do
balance,
trade-offs
and
stuff
maybe
later
on,
but
would
would
we
agree
that
this
should
be
left
in
us
number?
Four
for
now.
A
A
H
A
So
this
is
the
link
that
is
for
the
notes
for
this
session
cool,
and
so
I'm
just
typing
in
there
sort
of
as
we
go
through
what
we're
talking
about
a
bit.
Okay,
thanks,
thank
you.
Okay,
so
docs
was
the
next
one.
Then
after
docs,
I
see
serverless
okay,.
A
B
B
B
C
And,
from
my
point
of
view,
it's
regarding
serverless
provider-
I
am
going,
this
is
recorded,
so
if
you
are
aws,
google
functions
ager
functions
whatever,
so
you
can
listen.
What
am
I
thinking?
You
should
come
and
collaborate
with
us
like
it's.
I
find
it
extremely
weird
and
unfair
that
they
are
not
part
of
the
note
core
collaborator
community.
C
C
A
It's
still
useful,
I
think
in
in
terms
of
some
of
the
you
know,
depending
on
how
you
configure
your
your
like
kubernetes,
okay,
eventing
and
stuff,
like
that,
you
know
at
some
point.
You
still
are
starting
up.
B
Yeah,
but
usually
for
the
kubernetes
they're
longer
lived
than
things
like
functions
as
a
service.
Anyway,
it
would
be
nice
if
we
got
feedback
from
those
people
that
they
talked
about.
We
really
do
need
your
help
and
how
to
solve
your
problems.
C
C
A
That,
that's
that's
recognized,
understood
you
know
and
we're
not
in
the
state
that
people
would
like
us
to
be.
C
C
C
So
it's
you
might
be
in
certain
projects,
but
definitely.
A
You
know
feedback
from
michael
and
beth
says
we
don't
have
specific
asks
from
say
the
red
hat
server's
perspective
for
future
success
for
node.js
and
serverless.
We
need
to
maintain
properties
like
fast
start
small
size,
but
otherwise.
A
C
E
C
Better,
so
the
what
I,
what
I
said
is,
I
don't
think
we
are
seeing
a
lot
of
medium
to
big
enterprises
around.
C
I
think
that,
like
lambdas
and
and
functions
and
so
on,
are
either
really
used
into
the
automation
area
and
rather
than
you
know,
I'm
developing
a
full
application,
which
is
still
a
valid
use
case,
and
so
I
think
they're
less
widespread
than
the
reality
would
be
mainly
because
I
like
what
I'm
seeing
on
on
my
work
at
near
form
is
the
vast
majority
for
us
is
just
containers
literally
like
that
there
is.
There
is
functions
and
clouds
and
lambdas
and
stuff,
but
it's
it's
more
for
ancillary
topics
rather
than
the
bulk
of
the
code.
C
C
A
I
guess
the
the
the
the
question
to
ask
ourselves
is
like:
is
it
crucial
to
the
success
of
node
going
forward?
Do
we
think
that
we
make
it
a
priority
or
you
know,
do
we
think
that
you
know
that,
as
is
our
trajectory,
is,
is
good
and
like
you
know
whether
we
do
something
or
not
at
this
point
you
know
it's
like
because
I
guess
mateo.
What
I'm
saying
is
if
like,
if
we
thought
well,
we
you
know
the
fact
we
don't
know
what
to
do
is
different
from
us
like.
A
C
A
I
guess
do
we
do
we
know,
I
guess
we
don't
know
whether
from
my
perspective,
like
it,
some
of
the
other
ones,
it's
like,
I
can
look
at
them
and
say
yeah.
We
really
need
to
do
something,
because
if
we
don't,
if
we
don't
provide
some
focus
on
esm,
that
will
slow
down
overall
node.js
adoption
for
serverless.
A
A
It
may
be
just
fine
if
we,
if
we
had
more
involvement,
we
might
have
a
better
view,
but
it's
not
to
the
point
where,
like
we
have
to
make
it
our
top
priority,
to
go,
find
those
other
people
and
get
them
involved,
because
otherwise
the
project's
going
to
fail
right,
like
I
think
it's
like
node,
seems
to
be
well
used
in
serverless,
and
so,
if
it's
successful
well
that'll
pull
node
along.
A
A
So
so
sorry
I'd
go
back
so
mateo
you
were,
but
you
know,
would
you
advocate
that
we
we
added?
I
was
going
back
to
the
question
of.
Like
I
didn't
say
you
know,
we've
got
the
first.
Four
things
are
on
the
list,
but
it
sounds
like
we're
trending
towards
serverless
not
being
on
that
top
list
and
you
know,
does
anybody
think
that's
wrong.
C
I
would
add
a
sentence
to
the
to
the
topic
to
the
to
the
list
saying
that.
C
A
A
C
A
C
A
B
Webassembly,
so
there
are
blog
posts
about
in
general.
It's
node
is
one
of
the
easiest
runtimes
to
get
webassembly
up
and
running
on.
Currently,
it's
not
specifically
a
webassembly
runtime,
but
I
agree
that
this
should
take
a
priority.
We've
even
had
some
features
with
forward
compatibility
concerns
so
yeah.
I
agree.
B
C
There
is
also
the
from
my
test-
I
have
done
some
very
lightweight
tests,
but
for
my
tefl,
with
some
of
my
tests,
adding
moving
certain
parts
of
core
from
simplest
plus
to
webassembly
will
actually
give
performance
performance.
Improvements
like
there
is
even
the
question
of.
Can
we
shape
some
part
of
core
as
web
assembly
instead,
specifically,
the
one
I'm
talking
about
is
the
http
parser.
C
C
So
in
essentially
moving
the
http
parser
from
c
plus,
plus
to
inundici
moving
the
c
plus
pass
the
parser
from
c
plus
plus
to
webassembly
increased
our
perf
increase
our
support.
That's
the
that's
the
number
I
got.
I
can
links
and
use
the
pr
bradley.
G
G
C
C
In
fact,
it's
not
negative,
you
see
it's
look,
I
am,
it
was
even.
C
G
Yeah
and
that's
that's,
that's
the
other
thing
I
think,
to
keep
in
mind
with
webassembly.
Is
there
are
certain
areas
within
the
project
that
it
could
help
improve
the
project
and
so
by
prioritizing
it
externally
and
like
the
you
know,
the
external
interface
are
also
making
sure
that
we're
kind
of
able
to
sustain
one
something
that
I
think
is
really
valuable,
which
is
external
people
being
able
to
contribute,
which
is
why,
like
I'm,
you
know
sometimes
critical
of
us
using
rust.
G
B
B
G
I
I
think
I
I
think,
like
largely
what
I
mean
by
that,
is
you
have
to
learn
a
different
language
which
is
like,
if
you're
already,
writing,
javascript
you're,
you
can.
You
can
pick
up
on
the
dialect.
I
agree.
I've
been
playing
around
with
it
playing
around
with
cory
again
and
I
it's
a
struggle.
But
yes,
I
I
entirely
agree.
B
A
Fair
enough,
so
I
think
I
think
on
this
one,
that's
the
we
should.
Maybe
do
you
know
on
this
thing
not
going
too
deep
sounds
like
so
far.
I've
heard
most
people
say
that
we
we
do
think
this
is.
This
is
important
to
the
future.
Success
that
you
know
notes
has
has
a
reasonable
integration
with
wasm
and.
A
B
Remove
the
question
mark
most
likely,
I
don't
think
it's
necessarily
required
and
that's
a
complicated
conversation,
but
wazi
at
least
is
a
standard
that
people
could
agree
upon
for
cross-run
time
usage.
A
C
On
the
performance
side,
add
a
couple
of
links
into
the
thread:
one
shows
that
it's
it's
more
or
less
equivalent
or
slightly
faster,
and
then
there
is
another
link
that
shows
say
that
the
fact
that
we
now
can
use
cmd
on
inside
webassembly
improve
things.
Some
other
presented
point
on
it.
Okay,
so
it's
it's
significant
enough.
Just.
G
Okay,
can
I
just
ask
which
chat,
because
I
I'm
opening
all.
A
A
Okay,
so
let's
say
that
we
leave
that
on
the
on
the
list,
the
next
one,
the
next
highest
ranking
thing,
was
transaction.
A
B
I
think
it
is
what
apms
need
more
than
most
things
for
esm's
downfalls.
C
C
It's
I,
I
would
keep.
A
A
A
G
I
think
to
matteo's
point
like
having
those
things
where
we
can
tell
someone.
If
you
want
this,
you
can
pay
and
here's.
How
here
like
here,
is
the
path
to
do.
That
is
very
good,
because
it
makes
it
easier
for
that
justification
to
happen.
A
This
is
more
about,
though,
do
we
think
it's
important
for
the
success
successive
note
right
like
there's
the?
Can
we
just
ignore
this
and
node
will
be
just
as
successful
then
great.
If
it's
the,
then
it's
great,
if
we
just
say
well,
if
you
want
to
pay
here's
how
you
can
do
it,
if
we
think
that
you
know,
if
node
has
bad
observability,
less
people
are
going
to
use
it,
they'll
move
to
other
languages,
we
won't
be
successful,
then
we
might
want
to
have
it
on
our
list
is.
C
A
A
Right-
and
I
think
like
for
me
having
it
on
the
list,
would
mean
that,
for
example,
if
not
not
that
necessarily
you
know
our
project
is
going
to
go
out
and
build
the
transaction
tracing
prometheus
but
like.
If,
if
we
become
aware
of
things
they're
like
their
asks
in
node
core
or
supporting
for
apis,
it
is
it
being
identified
as
one
of
the
things
we
think
that's
important
for
the
success
that
hopefully
supports
us
supporting
those
asks
or
needs,
or
whatever.
C
I
would
also
include
the
diagnostic
tools
I
don't
know
like.
I
would
put
a
tesla
okay.
A
Yep
I've
got,
I
think,
you're
right,
like
diagnostic
tools
and
logging,
that
that
was
a
fairly
high
one.
So,
like
I
mean,
if
we
add
in
transaction
tracing
diagnostic
tools,
prospecius
style
metrics
that
got
quite
a
few,
you
know
possibly
from
the
same
people
but.
A
C
Would
you
like
to
help
out?
Okay,
and
you
know
right,
you
know
there
are
things
like
like
like
that
of
and
making
sure
that
those
from
some
of
those
things
stuff
is
already
possible.
It's
just
that
there
is
no
documentation
on
how
to
run
node.js
in
production
well,
which
is
slightly
different
than
I'm
writing
this
down.
I
think
this
is
a
good
point
missing,
docs.
C
That,
for
example,
let
me
let
me
let
me
make
a
few
examples.
Okay,
if
you
want
to
deploy
node.js
on
a
container
inside
kubernetes,
you
need
to
do
essentially
two
things
in
a
microservices
network.
First,
one
enable
dns.
Caching,
if
you
don't
have
dns
caching,
you
might
as
well
stop
doing
what
you're
doing
and
just
do
that.
C
Like
I
know
this,
I'm
giving
away
for
free
my
secret
sauce,
I'm
dog,
I'm
meeting
my
you
know
I
I'm
killing
my
own
business
to
some
extent.
Okay,
but
it's
you
know.
I
want
the
community
to
improve
so
dns
caching
and
then
the
second
one
is
http
keep
alive
to
be
there.
Now
those
things
need
to
be
documented
somewhere
and
we
don't
do
a
good
job
at
that
level
of
documentation.
A
A
A
B
I
B
G
B
So
v8
does
not
generally
have
a
specific
year
release
it
exactly
matches
for
ecmascript;
it
only
matches
parts
of
it.
So
that's
why
I
was
saying
more
like
can
I
use
data
because
we
can't
really
state
we
have
a
specific
version
of
javascript
supported.
G
Yeah,
I
also
think
that
I
know
I
know
we
really
haven't
seen
much
from
from
william,
but
node
green
was
also
kind
of
kind
of
this
to
some
extent
of
like
it,
it
showed
what
percentage
of
compatibility
with
yes
2015
we
had
for
every
version.
It
still
is
apparently
updating.
Although
there's
a
lot
of
errors
now,
but.
G
Yeah
that
I
think
that
is
like
a
closer
thing
to
to
what
we're
talking
about.
H
J
D
A
A
A
B
A
G
I
mean
I,
I
think
quick
is
important.
I
don't
really
know
enough
about
it
to
meaningfully
discuss
it,
because
I
I.
C
A
G
Necessarily
quick
but
maintaining
up-to-date,
http
and
like
following
http
as
it
evolves,
is
important.
I
don't
want
us
to
get
caught
in
a
situation
where
we're
we
have
http
one
baked
in
and,
like
you
know,
http
five
is
coming
out
and
we're
struggling
to
keep
up
and
like
we're,
you
know
struggling
to
get
http
4
in
or
whatever
having
some
good
portability
their
attachment
to
it,
and
I,
I
know
quick,
isn't
necessarily
http,
but
it's
like
well.
My
understanding
is
it's
close.
C
C
No,
I
it's
different,
it's
different,
michael,
because
that
is
about
end
user,
apis,
quick,
so
they
they
add.
Our
idea
for
the
client
is
that
you
would
be
able
to
use
quick
via
indici
completely.
C
E
A
E
C
So
it's
very
simple:
I
can
explain
it
at
uni.
It's
simple.
G
A
Okay,
but
we're
not
sure
whether
we
we
think
quick
support
is
key
to
node
success
yet,
but
it
would
make
sense
on
kind
of
a
a
watch
list.
C
A
A
All
the
rest
now
are
significantly
lower
we're
already
at
as
well
like
one
two,
three
four
five,
six
things:
seven
things
that
we
have.
A
A
B
But
yes,
similar
to
box
node
the
ability
to
generate
a
single
binary
doing
so
for
people
and
requiring
them
to
install
a
full
compiler
chain
might
not
fall
into
scope
for
it
might
yeah.
That's
a
discussion.
B
So
I
think,
right
now,
yesterday,
even
I
saw
a
video
claiming
that
node
was
not
secure.
It
is
never
secured
by
default,
and
this
was
by
a
security
researcher
at
a
university
giving
a
talk,
and
he
was
stating
that
dino
was
secure,
and
why
did
he
state
this
because
they
have
a
permission
system
in
place
essential?
B
The
claim
wasn't
that
dino
dino's
permission
system
is
without
fault,
but
simply
by
having
it,
it
invalidated
even
from
consideration
that
node
could
have
any
kind
of
security
associated
with
it.
B
B
There's
different
ideas
of
what
permissions
even
mean,
so
things
like
dino,
for
example,
which
is
was
being
hailed
as
a
very
locked
down
system,
suffers
from
prototype
pollution
attacks
on
its
core,
and
so
you
can
actually
go
and
load
a
third-party
module
and
basically
get
access
to
the
file
system.
Anyway,
if
part
of
your
program
does
node
has
a
policy
system
in
place,
but
it
doesn't
constrain
the
actual
apis
of
core.
B
It
only
constrains
module
loading
and
I
think
the
policies
work
fine
for
what
they
do.
I
don't
think
that
they're
good,
because
there's
no
default
policy
there's
absolute
permissions
by
default,
and
we
could
really
take
a
look
at
this
and
even
just
shipping.
A
second
binary
like
node
s
like
that
by
default
is
locked
down,
would
be
great
to
me
at
least,
and
it's
I
think
we
should
look
at
this.
It's
probably
higher
priority
to
me
than
some
of
the
things
we've
talked
about.
That's
a
personal
discussion.
So
that's
it
for
me.
G
B
G
A
I
I'm
like
I,
I
sort
of
get
the
if
it's
worth
doing,
then
whether
it's
hard
to
explain
is
is
kind
of
secondarily,
in
my
mind,
the
the
like,
if
we
suddenly
one
concern,
I
just
wanted
to
say,
is
like
if
we
do
say
that
we
support
a
tighter
security
model,
we're
going
to
need
to
be
pretty
sure
that
we
can
meet
those
expectations,
and
maybe
that
comes
back
to
the
you
know.
Maybe
some
of
the
explanation
part
like.
D
A
A
B
B
Yeah-
and
this
is
a
complicated
thing-
we've
tried
to
create
a
few
documents
on
security
models
for
node
in
general.
You
have
to
use
scoping
to
discuss
this,
and
so
you
can
declare
things
like
a
misconfigured
file.
A
misconfigured
policy
for
permissions
is
considered
out
of
scope
for
our
security
model,
so
you
have
to
properly
configure.
It
is
basically
what
you're
stating
one
fear
is
how
hard
it
is
to
configure
something
when
people
set
up
http
servers
when
they
generate
keys
inserts
and
stuff
like
that.
That
can
also
be
a
struggle.
B
You
have
to
generally
put
in
extra
configuration
whenever
you're
doing
these
security
things,
but
by
having
it
basically
be
inert
by
default.
Just
nothing
you
can't
it's.
B
I'm
I'm
not
gonna
say
that
this
security
model
is
good,
because
I,
I
definitely
think
things
where
your
blanket,
enabling
things,
particularly
via
the
command
line,
is
super
dangerous,
because
you're
giving
access
to
your
whole
application.
B
A
I
say:
let's:
if
we
step
back
to
the
yeah,
it's
not
easy,
but
the
question
is:
do
we
think
it's
key
to
this
successive
node
going
forward
that?
Could
you
know
that
doesn't
matter
whether
it's
so
easy
or
hard
it's
like?
Do
we
think
it's
important
that
us
that
we,
you
know,
we
think
we
make
it
a
priority
to
look
at
permissions
policies.
A
C
No
worries
I
wanted
just
to
say
that
we
need
to
have
something.
Okay,
to
be
honest,
most
dino
applications
are,
you
know,
run
at
a
very
high
permission
anyway.
So
it's.
C
Not
so
there
are
certain
things
like
I
was
discussing
recently
of
some
use
case
of
node,
okay
and
one
of
the
problems
that
we
had
was
that
we
have
required
in
order
to
do
his
thing.
It
needs
to
access
the
file
system.
However,
we
cannot
mount.
This
is
another
point
fsult,
and
we
cannot
mount
a
fake
required
tree
to
make
an
application.
C
You
know
run
on
top
of
a
zip
file
or
a
turbo,
for
example,
and
this
is
some
stuff
where
you
know
having
some
some
level
of
permissions
and
it's
some
of
these
things.
It's
I
understand
the
case
where,
like
the
dino
security
model,
makes
sense,
but
they're
very
narrow,
but
even
saying
something
like
hey:
we
have
a
security
system,
we
are
secure,
it's
even
though
very
few
of
our
users
will
use
it.
So
it's
to
some
extent
it's
marketing.
G
There's
actually
already
a
really
good
example
of
this,
and
it's
top
level
await.
We
shipped
top
level
of
weight
after
denno
did,
but
the
implementation
of
top
level
away
that
we
shipped
was
more
complete
from
what
I
understand
and
we
you
know
we
got
criticized
for
like
oh
you're.
Finally,
shipping
top
level
of
weight,
which
it's
like
the
the
person
who
proposed
it
it
is,
is
in
node
like
what
do
you?
I
don't
know
what
you're
talking
about
yeah,
it's
the
this
is
going
to
be
a
thing
and
that's
fine.
G
Honestly,
I
see
this
as
positive
that
there
is
now
competition
in
the
runtime
space
and
that
you
know,
there's
features
that
are
basically
getting
validated
for
free
for
us
and,
like
people
clearly
care
about
this,
whether
or
not
it
actually
is
good
and
they
can
shoot
themselves
in
the
foot
with
it
if
they
want
and
to
I,
I
just
want
to
kind
of
rewind
slightly
into
bradley's
point
about
node
s.
I
agree.
I
think
he
that's
the
the
correct
model.
G
B
So
one
thing
we
do
see
is
people
are
starting
to
pick
up
and
look
at
node
four
security
features.
We
did
have
some
microsoft.
Well,
we
are
about
to
get
a
pr
for
microsoft
for
os
integration
with
one
of
their
integrity.
Apis.
B
G
B
I
think
yeah,
it's
really
all
that
you're
doing
is
you're
inserting
if
it's
this
custom,
stripped
down,
build
turn
on
the
policy
file
with
an
empty
json.
That's
it
it's
just
like
insert
some
curly
brackets
in
a
specific
location
in
core.
That's
it
that's
the
actual
change.
G
A
Sounds
like
we're
agreed
that
permissions
policy
security
models,
so
so,
basically
something
where
we
work
like
working
node
towards
having
more
features
that
will
help
people
constrain
on
the
security
front
is
is
key
to
going
success
going
forward.
Yeah
we'll
still
need
to
figure
out
like
what
are
key
things.
We
would
want
to
do
to
support
that,
but,
like
that
is
a
thing,
it
makes
sense
yep.
A
Okay,
so
I
would
add
that
in
we
can
maybe
we'll
in
the
last
very
few
five
minutes,
we
could
talk
about
the
ordering
of
them,
but
are
there
any
others
from
the
list
that
we
should
sort
of
pull
out
and
add
to
that
list
that
we
have.
B
It's
pretty
separate,
it's
the
ability
to
not
have
run
time,
parsing
and
compilation
done.
Okay,.
A
A
B
Again,
snapshots
can
do
it,
but
that's
complicated
we're
in
a
better
place
for
user
land
snapshotting
than
we
were
previously,
but
I
don't
think
it's
gonna
be
in
the
short
term,
realistic.
I
think
there's
more
like
four
four
years
down
the
line.
G
B
C
Yeah
I
use
process
dot
road
underscore
road
debug.
So
yes,
I
see
the
the
experience
here
is
not
nice.
Okay,.
A
B
C
A
C
I
would
say
something
like
that:
yes,
it's
probably
not
the
api
currently
is
fine,
but
it's
it's
missing
something
on
the
edge
to
makes
things
good
like
I
can.
D
A
G
A
A
C
I
know
I
know
I
okay,
so
one
of
my
the
the
single
binary
stuff.
It's
so
would
be
so
much
interesting,
especially
if
it
can
give
a
significant
performance,
lower
bootstrap
time
for
the
application.
C
C
It's
you
know
it's
if
we.
G
C
Delete
it
like
make
it
that
we
can,
you
know,
tap
into
some
special
magic
that
would,
I
don't
know,
precompile
the
code
preload,
it
load
it
from
an
area
of
memory,
that's
actually
faster
to
load
instead
of
file
system.
Again,
when
you
do
all
the
requires,
you
know
it's
actually
a
lot
of
work,
just
loading,
an
ojs
app.
B
C
A
C
G
Think
we
can
live
without.
I
think
we
can
live
without
it,
but
more
and
more
we're
seeing
that
this
is
a
thing
that
it
is
getting
to
the
point
of
the
the
the
the
permissions
policies
stuff,
like
I
think
denno
does
this
like
by
default
right.
This
is
like
how
dinner
works.
Is
you
ship,
a
single
binary.
G
Oh
so,
okay,
sorry,
I
thought
it
was
by
default.
I
don't
know
I
try
not
to
use
deno
yeah,
so
deno
can
do
this.
So
you
know
if
you
want
to
look
at
it
from
that
same
model
of
marketing,
so.
B
This
is
complicated
the
way
denno
does
it
can't
be
signed
properly.
So
the
one
nice
thing
about
how
node
does
it
is
it?
Does
it
during
the
compilation
step
and
during
your
you
know,
full
compilation,
tool
chain.
You
can
get
proper
operating
system
signage,
so
you
could
put
it
in
an
app
store
or
package
manager
as
a
single
file.
B
I
would
prefer
that
a
user
not
have
to
install
a
compiler
chain.
I
don't
necessarily
think
decoupling.
It
with
compilation
is
a
good
idea.
I
just
don't
want
a
user
to
have
to
set
up.
You
know
how
to
compile
node
in
order
to
create
this
yeah.
A
B
B
It's
just.
I
just
want
people
to
either
use
a
service
or
have
a
single
binary
that
will
let
them
do
it.
I
don't
think
it
necessarily
needs
to
be
node,
because
I
don't
think
this
is
a
typical
use
case
to
generate
single
binaries,
but
I
I
don't
think
they
should
have
to
install
everything
under
the
sun
in
order
to
make
dot,
slash,
configure
and
make
work,
which
is
what
they
would
need
to
do
essentially
for
box
node.
A
Okay,
I
was
thinking,
though,
that
like
for
me,
the
interesting
part
is
that
once
you
distribute
once
you've
built
it,
you
can
distribute
it
easily.
You
can
and
from
you
know,
from
matteo's
comment
that
if
they
can
start
and
run
faster,
I
wouldn't
have
been
worried
that
you
actually
have
to
work
a
little
harder
to
do.
That.
B
So
now
we
have
a
2014
talk
from
me
about
this,
where
I
did
it
using
third-party
main.
If
you
want
to
go,
look
at
it,
it's
from
entire
js,
that's
based
off
a
zip
architecture.
A
B
A
Okay,
I
think
we're
we're
getting
in
the
weeds
a
little
bit
again.
So
maybe
we'll
we'll
put
the
single
binary
on
the
list
for
now,
and
you
know,
I
think
we'll
need
us
we'll.
What
I
propose
is
we
take
like
a
20-minute
break
if
that's,
okay
or
15
or
20
minute
break,
come
back
then
talk
about
the
the
second
second
part,
and
then
the
in
the
third
part
we'll
review
this
list
again.
To
kind
of
like
say,
is
everything
on
that
list?
A
C
A
A
A
G
G
F
D
A
A
But
maybe
can
people
put
their
hands
up
in
the
and
for
who's
here
and
we
can
see
that.
A
Okay,
we
have
most
people
so
we're
down
to.
Let
me
see
here
everybody's
back
for
that
rather
than
two,
so
I
think
we're
almost
25
minutes
after
other
than
maybe
beth
are
you
here?
A
J
A
A
A
So
this
was
the
agenda
that
we
had
for
the
the
next
session.
You
know,
I
think
we're
we're
a
little
behind,
so
maybe
we'll
try
and
keep
this
one
to
say.
50
minutes
we'll
see
how
that
goes,
but
it
was
covered
in
this
particular
issue
to
start
with,
and
really
it's
it's
everything
we
want
to
talk
about
in
terms
of
what
the
next
10
years
should
look
like
for
collaborators.
A
A
A
Maybe,
if
nobody's
jumping
in,
we
can
just
start
with
the
ones
that
are
listed
there
like.
A
C
Yeah
sure
which
is
the-
and
we
talked
a
little
bit
about
this
in
in
our
call
yesterday,
whatever
but
the
composition
of
the
security
trading
and
genetically.
How
do
we
make
sure
that
node.js
is
secure
right.
A
C
I
mean
in
the
sense
of
not
shipping
vulnerabilities,
so
yep,
and
that's
something
that
I
would
it's
a
it's
part
of
our
leadership
model
and
responsibility
to
some
extent-
and
I
don't
know
it's,
I
think
it's
something
that
should
be
on
the
table
or
now,
from
my
point
of
view,
it's
something
that
we
should
change,
because
I
am
the
one
one
of
the
people.
That's
doing
the
heavy
lifting
on
on
that.
I
it's
yeah.
A
I
think
that's
that
that's
a
good
one
to
cover
under
the
leadership
model,
because
it's
kind
of
tied
to
it
and
we
could
go
different
ways
like
does
it
make
sense
that
it's
tied
to
it,
and
you
know
we
could
say
no
or
we
could
say
yes
and
if
yes,
it
might
mean
we
have
certain
expectations
that
kind
of
stuff.
A
So
okay,
so
I
added
that
under
the
leadership
model,
I
don't
know
you
you
know,
do
we
want
to
start
in
terms
of
the
the
order
that
was
there
like
contribution
workflow
or
do
we
want
to
start
with
one
of
the
other
ones.
A
What
we
want
to
do
is
like
what's
the
key
thing
for
ongoing
success,
so
are:
is
there
anything
beyond
these
three
things
that
we
should
talk
about?
In
that
context,
like
you
know,
is
there
a
really
big
problem
that
somebody
sees
that
we
need
to
make
sure
we
address
in
terms
of
contributors,
you
know
and
or
the
experience
for
collaborators
like,
what's
the
most
important
things
that
we
talk
about
on
that
front,.
D
I
think
part
of
it
is.
We
need
to
make
sure
we
maintain
the
level
of
contribution
we
have
across
the
board
or
increase
it,
hopefully,
but
specifically
in
certain
working
groups
as
well.
We
need
to
make
sure
that
we're
always
covered
and
whether
that
means
making
sure
it's
a
nice
experience
for
the
people
we
have
or
making
sure
that
it's
easy
to
bring
new
folks
on
when
people's
life
changes
and
they
have
to
move
on
or
dedicate
less
time.
I
think
it's
both
of
those
you
need
to
keep
up.
G
G
Oh
okay,
sorry,
I
think
the
latter
part
of
what
beth
said
has
an
additional
component
there,
which
is
we're
all
gonna
die
someday
like
we're.
We're
we're
not
gonna,
be
doing
this
forever,
whether
it's
we
retire.
We
get
hit
by
a
bus
or
there's
some
tragic
air
collision
with
all
the
collaborators
on
it.
When
we're
going
to
collaborate
or
so
it's
something
making
sure
that
people
can
continue
to
contribute
and
like
there,
there
are
people
who
succeed
us
or
yeah
succeed.
I
think
that's
right,
word
secede!
No!
Whatever,
anyway,
it's.
G
A
G
What
my
brain's
breaking,
but
yes,
we
we
have.
G
You
know
at
least
I've
noticed
that
we
have
pulled
in
less
people
into
leadership
than
we
had
previously
and
I'm
concerned
about
that,
for
the
longevity
of
the
project
and
for
the
perpetual
motion
of
it
to
continue
working
like
largely
the
people
who
are
largely
not
holy,
but
largely
the
people
who
are
in
leadership
now
were
in
leadership
four
years
ago,
and
that's
concerning
to
me
that
we
we're
not,
you
know,
adding
new
people,
and
I
think
that's
something
that
kind
of
ties
into
that.
Last
point
of
what
beth
said.
G
A
A
A
I
guess,
is
there
also
an
element
of
like
making
it
people
like
to
maintain
that
we
need
people
who
have
time
to
be
able
to
contribute,
and
how
do
we
promote
that
like
because
I
think
some
people
struggle
with
like
they'd
like
to
contribute
more,
but
they
don't
have
time
in
their
jobs
or
roles
or
right
like
that?
That,
I
think,
in
my
mind,
is
a
is
a
blocker
for
some
people.
D
G
I
I
think
that
we
are
the
only
open
source
project.
I've
seen
that's
focused
on
that
as
much
as
we
do,
and
I
think
I
think
there's
other
things
we
can
do
that
kind
of
make
that
a
not
problem
like
there
are
absolutely
people
who
want
to,
but
there's
other
things
you
can
do
to
just
enable
the
people
who
do
have
that
time,
and
I
I
think
it's
it's
fine
to
find
to
work
on.
G
You
know
figuring
out
how
to
enable
that
you
know
people
to
get
that
time,
but
I
don't
think
that's
the
primary
blocker
like
there's
people
contributing
to
other
open
source
projects
right
and
like
people
are
starting
in
other
open
source
projects
and
kind
of
getting
into
leadership
and
other
open
source
projects.
So
I
I
don't
necessarily
believe
that
that's
the
biggest
blocker
we
have
is.
We
can't
find
people
there
aren't
people
who
have
time.
I
I
think
that
those
people
exist,
we're
just
not
creating
the
incentives
for
them
to
contribute.
To
note.
A
That
would
be
an
interesting
one
for
me,
like
a
lot
of
other
projects
that
I
see
even
within
the
foundation,
sometimes
have
a
fairly
strong
contingent
from
one
or
two
companies
so
like
what
would
be
a
large,
you
know
open
source
project
that
you
think
is
doing
better,
that
we
might
look
at
as
an
example.
G
To
contribute
right
and
right,
but
there
is
a
number
of
other
people
who
come
in,
who
are
stakeholders
who
participate
actively.
G
So
right
like
there
is
a
majority
group,
but
then
there
are
a
number
of
people
who
are
just
as
active
in
their
own
roles
who,
like
it's,
not
a
it's,
not
a
a
team
of
people.
It's
a
single
person
who
come
and
contribute
and
because
they've
they're,
because
their
company
has
cares
about
electron,
right
or
because
and
because
they
care
about
electron
as
well.
A
Right-
and
I
guess
it's
like
that-
was
back
to
the
like:
do
we
have
enough
companies
supporting
their
contributors
and
coming
this?
I
was
just
wondering
if
that
was.
That
was
an
issue
we
should
think
about,
but
I
guess
you
know
maybe
take
your
example
of
babel
like
they.
You
know.
That's
an
example.
You
think,
where
they're
doing
some
things
we're
not
which
might
pull
in
more
contributors.
G
I
from
what
I've
seen
yeah
like
they're
they're,
pretty
good
at
lifting
people
up
and
enabling
them
to
you,
know,
contribute
and
getting
people
in
yeah.
G
I
don't
know,
I
don't
know
if
they're
codified,
like
I
don't
know
if
there
there's
a
document
with
the
practices
that
they
follow,
but
they're
better
at
it
than
we
are.
I
think.
G
A
G
Well
but
see
the
other
thing,
there
is
like
what
how
how
active
are
those
people
like
the
the
three,
the
the
two
active
additional
active
people,
might
need
be
more
active
than
the
additional
100
making
a
single
commit.
A
A
That
would
be
an
element
of
this
discussion
as
well
right
sort
of
what's
the
shape
of
of
what
we
think
will
help
lead
to
success
and
make
it
a
place.
People
want
to
contribute
to
and
and
at
the
same
time,
help
us
to
move
forward
and
be.
C
C
C
Could
we
get
some
some
some
funding
that
way
and
to
sponsor
some
people?
I
I
don't
know
okay,
I
am
just
at
this
point
in
time.
There
is
no.
A
Except
for
you,
can
you
can
commit
your
people,
but
you
can't
say:
here's
x
dollars
to
fund
a
person
yep.
C
Yes
or
a
feature,
okay
or
even
like
saying,
okay,
let
me
be,
I
know,
I'm
going
back
to
to
something
very.
J
C
Right
so
I
don't
know
if
there
is
an
answer
to
this,
I'm
just
making
it
visible
from.
A
Right
and
I
guess
we'd
wanna
like
that,
would
be
a
you
know.
We'd
want
to
as
a
project
decision
to
say:
does
that
actually
make
things
better
or
worse
right
like
it's
like
I'm
sure
we,
you
know,
but
that's
interesting.
I
think
you
know
we
should
be
looking
at
everything
right
like
you
know,
it's
kind
of
like
what
will
make
us
successful
going
forward
and
if
there's
dollars
that
aren't
being
spent
in
the
project,
because
there's
a
for
some
reason
that
might
be
spent,
you
know
we
want
those
dollars
to
support
the
work.
J
We've
never
really
done
a
good
job
because
of
how
node.js
was
started.
Pre.
What
I
would
say
the
kubernetes
excitement
right
right
now.
A
lot
of
money
is
being
poured
in
that
ecosystem
right
because
they
have
the
landscape.
They
have
the
cloud
native
foundation.
They
there
there's
a
lot
of
excitement
there
and
even
though
we're
a
backbone
tool
around
serverless
and
other
containers
and
everything
we're
not
being
marketed
a
guest
or
presented
in
the
same
level
as,
for
example,
even
you
know
postgres
sql
server,
which
is
just
as
old
as
node.js.
J
J
G
I
I
definitely
have
some
thoughts
on
that.
I
I
spend
a
lot
of
time
thinking
about
this
because
of
my
job
and
the
intersections
of
like
you
know,
I
sit
on
a
team
that
half
of
my
team
contributes
upstream
to
kubernetes
and
I
also
like
work
a
lot
with
the
cncf
and
linux
foundation
and
other
standard
like
stuff
like
that.
J
I
think
I
didn't
mean
to
cut
you
off,
but
what
I'm
really
thinking
about
is
not
kubernetes
per
se,
but
if
you
look
at
the
whole
ecosystem
all
around
it,
how
there's
a
lot
of
investment
going
on
right,
yeah
right
now,
this
investment
is
where
the
intersection
between
security,
and
that
is
playing,
is,
is
sort
of
taking
on
for
the
last
two
or
three
months
to
me.
So
my
question
is
is,
but
even
though
every
company
uses
uses
node,
it's
it's
not
considered
in
the
same
same
way,.
G
I
think
there
is
a
very
specific
reason
for
that
and
that
it
it
is
that
the
cncf
is
effectively
the
npm
registry
of
cloud
native
it
or
like
whatever
you
want
to
call
it
like
all
the
stuff
that
falls
under
that
scope,
that
is
the
registry
and
because
it's
not
something
that
you
can
just
publish
to,
but
you
have
to
have
there's
processes
and
stuff
around
it,
and
it
is
a
neutral
airports,
neutral
body
and
money
is
involved
with
it.
G
It
incentivizes
money
to
be
applied
to
those
spaces,
and
I
I
at
this
point
I
genuinely
don't
think
that
at
least
the
javascript
ecosystem
maybe
not
exclusive
to
all
ecosystems,
but
I
think
the
javascript
ecosystem
at
least
cannot
ever
attain
that
same
structure
because
of
how
how
we've
already
structured
ourselves-
and
we
will
always
be
living
in
some
some
percentage
or
some
margin
of
of
that
funding.
G
G
The
the
exception
to
this
is
like
serverless,
but
even
docker
containers
you're
just
getting
into
the
same
thing
as
you
know,
kubernetes
right,
like
you're
getting
into
that
ecosystem,
and
so
then
node
in
javascript
doesn't
matter,
and
so
that's
why
there's
able
to
be
such
investment
in
those
tools
and
not
necessarily
in
javascript
or
at
least
that's
my
my
my
experience.
J
The
other
question
I
just
have-
and
it's
just
a
sidebar
only
based
on
what
you're
saying
is-
is
how
do
we
improve
the
visibility
of
nodejs
and
this
ecosystem
and
the
javascript
ecosystem
within
the
cloud
native
landscape
period?
Because
right
now
you
know,
if
you
just
think
about
no
sequel
in
sql
right
that
that
is
something
that
you
can
see
and
identify
resources
in
the
cloud
native
ecosystem.
J
If
that's
where
it
is,
but
you
can,
but
I
don't
really
see
javascript,
node
or
typescript
or
dart
or
any
of
those.
It's
just
I'm
not
trying
to
create
another
problem.
I'm
just
saying
you
know
we
need
to
be
able
to
figure
out.
How
do
we
create
cross-visibility
where
we're
part
of
these
other
ecosystems?
J
How
do
we
do
that?
And
if
we
can
do
that,
and
then
that
may
help
us
get
more
attraction
in.
J
A
I
mean
back
back
to
mateo's
point
of
like
do.
We
think
we
would
get
more
collaborators,
so
you
know
this.
This
section
is
like
for
collaborators
like
one.
Would
we
get
more
collaborators
if
there
was
like
a
pool
of
dollars
that
people
could,
you
know,
do
work
for
and
what
would
the
overall
collaborator
base
feel?
How
would
they
feel.
G
Perhaps
my
perception
is
off
there,
but,
like
I
I
can
see
I
have.
I
have
heard
people
make
assertions
around.
You
know
direct
funding,
as
employees
and,
like
you
know,
employ
sponsoring
employee
time
or
sponsored
employee
time
as
the
best
way
or
the
most
effective
way
to
to
contribute
to
node
right
now
and
like
the
path
forward.
Basically,
like
people
have
made
that
assertion-
and
I
think
that's
valid-
I
also
don't
think
it
should
critically
exclude
this
avenue.
I
think
I
think
this
avenue
is
something
that
we
could
and
should
pursue.
G
I
also
think
it's
rather
at
odds
with
the
model
of
the
foundation.
So
that's
I
I
foresee
challenges
with
that,
as
there
have
been
challenges
in
other
projects
as
well
with
this.
So
that's
that's
one
thing.
A
A
C
D
G
I
mean
the
the
one
caveat
I
put
on
that
is,
like
you
know,
being
close
with
people
who
are
in
that
group
of
people
who
are
getting
paid.
It's
not
I,
I
would
say
it's
random
that
they're
getting
that
much
money,
largely
because
like
if
you
look
at
my
browser
crash
trying
to
open
their
open
collective
but
like
there
was
some
donation
from
like
a
crypto
company
that
was
like
200
000.
G
It
was
just
a
one-time
thing
that
they
just
poured
200k
into
it
and,
like
then,
you
know
the
next
year
that
money
that
200k
is
gone
and
said
like
they
have
to
kind
of
keep
doing
that.
The
other
thing
there
is
that,
like
a
non-trivial
amount
of
time,
there's
been
criticism
around
this
a
non-trivial
amount
of
time
is
ends
up
investing
in
getting
money
into
that
fund.
Like
into
that
that
pool
you
have
to
do
work
to
do
that.
G
Right,
like
you,
have
to
spend
time
and
effort
getting
people
to
agree
to
give
you
money,
then
that
the
optics
of
that
are
that
you're
not
doing
as
much
work
and
that's
not
necessarily
good
like
I.
I
don't
agree
with
those
optics,
but
that
is
that
is
the
optics
of
it
and
so
that,
yes,
there
there's
challenges
with
that
model
as
well,
and
I
I
think
it
is
still
a
model
we
should
explore
and
partially
because
we
can
help
normalize
it
in
the
ecosystem.
G
I
think
that
this
model
is
not
going
away
and
helping
and
enable
it
is
something
that
is
potentially
positive,
even
if
it's
we
fail
at
doing
it
and
here's
why,
like
taking
that
failure
on
as
a
project
at
our
size
is
totally
fine.
A
So
I'm
gonna
say
again
like
we
did
on
the
technical
one.
Let's
we're
we're
not
gonna
solve
this,
get
into
all
the
details,
but
we
could
add
to
our
list
of
priorities
things
things
we
think
that
are
important
priorities
for
the
next
10
years.
Successes
one
could
be
like
ways
of
getting
funding
to
collaborators,
and
you
know
we
can.
Then
you
know
later
on
delve
into
like
what
the
different
ways
how
we
would
do
that
and
prioritize
versus
other
things
that
we
might
come
up
with.
D
A
Yes,
okay,
so
you
know
that
that
was
a
good
one,
so
maintaining
bethany
also
said
maintaining
level
of
contribution.
Is
that
a
separate
topic?
I
guess
that
that
really
is
right,
so
maintaining
level
of
contribution.
A
I
would
put
into
that
like
which
I
think
tierney
mentioned,
which
was
a
succession
planning.
G
A
A
A
F
Just
on
the
contrary,
sorry,
I
think
it
could
be
also
great
to
think
to
to
to
find
a
way
to
involve
company
and
I'm
not
thinking
about
tech
company
like
google,
amazon
and
every
kind
of
company.
I
work
for
an
insurance
company.
I
use
node.js
every
day,
but
just
trying
to
find
time
and
to
let's
say
justified
to
have
some
time
to
attend
meetings
or
do
and
write
code
outside
of
the
core
business
of
the
company
is
always
hard,
at
least
in
france.
So
it's
the
same.
F
A
Is
there
something
that
we
should
be
thinking
about
can
be
doing
to
help
them
like
if
it's
not
strictly
a
we've
talked
we
talk
about
other
problems
like
you
know,
it's
hard
to
get
involved
because
documentation
or
technical
issues,
but
like
another
one
is
just
like:
can
you
get
time
from
your
company
to
do
it?
I
think
that's
what
you
were
just
saying
right.
A
F
A
D
I
wonder
if
us
just
having
this
list
of
future
priorities,
might
help
with
that.
If
they
can
see
something
like
loaders
or
better
diagnostics
on
our
roadmap
and
things
we
care
about
and
things
we're
trying
to
push
forward.
I
think
that
might
help
convince
them
because
they're
things
they
probably
need.
G
So
I
I
definitely
I
agree
with
that.
I
mean
I've
been
asked
internally
at
microsoft
before
you
know
like
what's
the
road
map
for
node
and
I
have
to
say
there
isn't
one,
and
you
know
I
explained
that,
but
that's
dis
disheartening
to
certain
folks.
It's
also
challenging
for
certain
folks
who
are
in
say
a
serverless
space
who
you
know
something
major
coming
down.
The
pipeline
is
going
to
impact
how
they,
how
they're
able
to
serve
their
customers-
and
I
end
up
helping
them,
but
that
that's
a
thing
that
happens.
G
G
This
is
a
valuable
thing
for
you
to
do
and
I
think
talking
one
of
the
things
I
think
we've
not
done
a
great
job
as
or
at
is
figuring
out
who
those
are
and
who,
how
we
need
to
do
that.
I
think
we
have
a
base
of
people
who
won
we've
already
done
that
with,
and
we
could
go
talk
to
and
say
what
was
convincing
for
you
like.
We
can
go,
get
that
information
and
two.
We
have
a
base
of
people
who
that's
not
been
a
successful
thing
for
and
we
can
go
ask
them.
G
Why,
like
I'm
sure
you
know,
I
know,
I
know
there
was
at
some
point.
I
was
talking
to
someone
to
capital
one
and
they
have
five
thousand
no
devs
or
had
five
thousand
no
devs.
I
don't
know
if
they
still
do
that
was
four
years
ago
or
something
kind
of
wild
that
they
are
spending
5000
people
on
node
and
one
the
project
doesn't
know
about
it
too.
G
They're
not
contributing,
like
that's
a
kind
of
like
that
is
the
case
of
someone
like
in
the
cncf.
That
would
be
like
actively
contributing
if
there's
5000
people
investing
in
kubernetes
right.
So
that
kind
of
thing
is
something
that
you
know.
We
could
go
talk
to
them
and
say
hey.
Why
why
why
didn't
you
contribute?
G
What
did
we
feel
it
doing
to
to
get
you
involved,
and
I
think
that
there's
going
to
be
multiple
companies
like
that
right,
like
I,
I
know,
and
I'm
I'm
sure,
other
people
who
have
worked
in
services
in
this
call
know
all
of
the
companies
or
many
many
companies
that
have
a
lot
of
large
node
investment
that
don't
participate
so.
A
F
I
think
it's
it
can
also
join.
I
think
we
talk
on
another
call
about
why
not
gs
is
a
great
technology
to
choose
for
one
company.
I
think,
if
I
remember
right
so
it
could
be
also
the
same.
Why
contributing
is
an
advantage
to
a
company.
A
A
A
A
I
think
the
two
things
we've
already
like
I'm
actually
rearranging
a
little
bit
like
it's
sort
of
maintaining
growing
the
level
of
contribution,
and
that
is
like
within
you
know,
ways
to
get
funding
to
collaborators.
Succession
planning
helping
people
from
companies
justify
make
the
case
to
have
time
to
contribute
does
all
seem
related
to
me.
Does
that
make
sense
to
people.
A
In
in
terms
of
that
specific
thing,
like
do,
we
believe
there
so
since
we're
since
we're
sort
of
diving
into
that,
we
got
that
list.
I
think
part
of
the
the
reason
this
was
first
suggested
was
like.
Are
there
things
that
we
think
we
should
do
differently
within
the
project
that
would
help
maintain
grow
contributors
like
technically
or
you
know,
you
could
say:
oh
it's
too
hard
to
to
contribute,
and
so
people
come.
A
Then
they
get
turned
off
and
they
leave
that's
our
major
problem
or
you
could
say
well,
you
know
to
actually
make
a
substantial
contribution
you're
going
to
have
to
spend
some
time
you're
going
to
have
to
invest
and
what
we've
got
you
know,
while
isn't
perfect
shouldn't,
be
the
determining
factor
as
to
whether
you're
going
to
stick
around
or
not
so
I'm
just
sort
of
like
poking
at.
Do.
We
think
there's
specific
things
in
terms
of
like
what
you
have
to
do
to
contribute
that
we
would
want
to
look
at.
A
I
D
F
A
No,
no,
it's
they've.
It's
been
re.
A
So
that,
instead
of
like
looking
for
mentees
and
then
trying
to
match
with
mentors
it's
the
the
men,
the
mentorship
program
has
gone
out
to
a
number
of
groups.
They
did
a
presentation
at
the
tsc,
not
not
so
long
ago,
but,
for
example,
I'll
give
you
my
experience.
They
they
approach
the
note
api
team
and
we
work
with
them
to
say:
okay,
like
here's.
What
would
make
you
know
some
of
the
skills
that
somebody
would
want
that
would
position
somebody
to
be
success,
successful
they
then
went
out
and
looked
for
mentees.
A
They
came
up
with
some.
You
know
kind
of
kind
of
like
of
an
interview
and
found
a
good
match,
and
then
those
people
have
joined
the
node
api
team.
We
already
had
like
a
weekly
meeting,
so
they
come
to
that
weekly
meeting.
We
have
an
opportunity
to
talk
to
them,
ask
if
they
have
questions
and
so
we're
mentoring.
We
we
actually
now
have
two
mentees,
so
it's
a
much
more
targeted
small
scale
like
let's
find
people
who
are
interested
in
committing.
A
You
know
significant
time
over
time.
Like
you
know
it's
it's
not!
I'm
gonna
do
my
second
pr.
It's
like
yeah
I'll,
come
to
your
meet
I'll
come
and
take
on
some
tasks
come
to
the
weekly
meeting
for
months,
and
then
you
know
in
in
return
to
the
rest
of
the
team,
mentors
and
works
with
them,
and
that
kind
of
sounds
similar
to
you
know
what
beth
did
sort
of
informally.
A
G
Sorry
yeah
it
just.
G
Really
effective
like
it's,
it
seems
to
be
working
well,
they
they're
doing
a
very
good
job.
A
A
Because
I
mean
I
think
if
this
you
know,
if
there's
a
group,
we
come
up
with
this,
and
we
say
this
is
important.
It's
something
where
I
you
know.
I
know
the
mentoring
team
has
been
trying
to
go
out
there
and
say:
hey
anybody,
anybody
anybody
have
somebody
anybody
willing
to
mentor
but
like
it
may
be
something
that
we
can
try
and
support
more
strongly
or
you
know
talk
about
it
as
as
the
next
10
group
like.
A
What
can
we
do
to
support
that
mentoring
initiative,
because
I
think
they've
got
you
know
like
I
said
the
model
seemed
to
work
fairly
well
for
node
api
from
what
beth
said
it
kind
of
fitted
fit
that
that
earlier
the
model
that
she
found
useful,
but
I
think
they're
not
getting
as
many
groups
coming
to
them
and
saying
yeah
we
could
we
could
use
a
mentee.
We
can
support
a
mentee
right.
C
C
Right,
it's
not
easy
to
contribute,
especially
because
you
need
to
know
you
need
to
have
to
know
a
subsystem
somehow
so,
for
example,
if
you
not
to
if
you,
if
you
want
to
contribute
to
http,
you
need
to
have
a
very
cool,
great
idea,
cool
a
good
idea
of
what
this
pack
for
http
1.1.
C
Says
this
is
art
okay,
these
are,
we
are
talking
about
hard
skills.
On
the
other
hand,
if
you
need
to
if
you're
talking
node
streams,
for
example,
you
need
to
have
been
working
with
the
staff
for
a
long
long
time,
and
it's
not
easy
to
have
those
skills
like
simply
put.
A
Right,
I
think
that's.
The
key
thing
is
like
the
expectation
has
got
to
be
that
the
mentee's
making
a
longer
term
commitment
in
terms
of
time
right
because
otherwise
you're
right,
it's
not
gonna
like
we
don't
have.
I
think
there
are
challenges
we
don't
have
a
lot
of
easy
stuff,
yeah
or
quick
and
easy
right,
and-
and
I
guess
that's
where
we
were
part
of
the
earlier
thing-
is
like
at
one
point-
we
did
have
a
fairly
big
push
on:
let's
try
and
get
as
many
new
collaborators
kind
of
like.
A
First
first
pr
landed,
you
know-
and
I
think
that
was
like
we
get
people
interested
they're
invested,
but
we
could
think
about
like
does
that
actually
work,
and
is
that
key
to
our
future
success?
Or
is
it
we
want
to?
You
know
we
need
to
focus
our
efforts
on
smaller
number
of
people
who
will
have
more
time
or
because
those
are
different,
sort
of
different
approaches.
G
D
D
G
A
few
we
got
a
few
absolutely
but
out
of
like
300
at
each
event,
it
was
like
two
like
that
that
isn't
really
like.
That
is
not
a
return
in
like
the
way
that
I
think
we
were
hoping
it
would
be.
I
mean
I
could
be
wrong.
Maybe
the
expectation
was
not
that,
but
like
it
was
a
very
small
number
compared
to
how
many
people
were
actually
showing
up
and
you
could
actually
see
it.
I
post
I
posted
the
links
in
the
zoom
chat.
You
can
see.
G
Which
is
you
know,
that's
fine,
but
I
I
don't
think
that
it
I
like.
If
we
have
to
do
that,
much
work
to
get
like
you
know
a
handful
of
contributors.
That's
I
don't
think
the
best
or
most
effective
way
to
exert
that
energy.
A
So
I
I'd
say
again
just
for
time.
We
should
leave
on
like
targeted
mentoring
on
that
list,
but
and
and
I'm
back
to
like,
are
there
other
things
into
maintaining
growing
like?
Are
there?
Is
there
something
about
our
you
know?
One
of
the
things
that
was
on
this
initial
list
was
the
contribution.
Workflow.
Is
there
something
about
the
contribution
workflow
that
we
think
would
we
would
significantly
change
the
level
of
control?
A
I
and
I
don't
want
to
say,
like
active
or
contributors
or
whatever,
but
like
the
level
of
contributions
that
we
get
and
not
strictly
by
like
hey,
did
they
do
a
first
commit
because
that
that
may
or
may
not
it's
more
like
of
meaningful
contributions?
I
guess
is
that,
and
I
don't
want
to
say
no,
I'm
meaningful,
but
I'm
hopefully
trying
to
say,
like
you
know
something
which
has
which
which
moves
the
needle
on
that.
A
A
Does
the
lock
I'll
just
so,
you
know
make
things
that
can
be
controversial
out.
There
is
the
lack
of
anybody.
Chiming
up
say
that
yeah
we're.
You
know
our
contribution.
Workflow,
we
all
think
is
okay.
You
know.
Obviously
things
can
always
be
better
easier,
but
like
there's
not
something
that
you
can
say,
oh
well,
if
we
change
this,
that's
going
to
make
a
massive.
G
Difference
I
mean
I
I
have.
I
have
critiques,
but
also
you
know,
I'm
not
a
core
contributor
and
I
not
it's
not
my
place
to
compete.
A
G
G
I
backboard,
like
just
basically
reducing
the
pain
in
in
prs,
is,
I
think,
something
that
would
be
useful.
It's
something
that
I've
seen
people.
A
The
like
the
I'm
just
trying
to
understand
like
the
back
porting
part,
I
think
it's
and
beth
can
correct
me
if
I'm
wrong
the
main
the
main
issue.
There
is,
if
things
don't
land
cleanly
right.
D
Yeah,
I
kind
of
feel
yes,
the
kind
of
like
review
process
can
be
somewhat
straining
at
times
and
also
be
nice.
If
things
were
a
lot
more
automated
like
we
could
click
the
merge
button
on
github,
but
those
those
things
for
me
are
at
least
livable.
It's
really
coming
up
with
the
new
code
that
actually
needs
to
be
written.
D
I
don't
I
don't
see
the
myself
the
technical
kind
of
landing
things
yesterday
repeating
is
what's
limiting
or
bottlenecking
our
contributions.
I
kind
of
feel
it's
the
lack
of
guidance
to
folks
on
what
needs
to
be
contributed.
What
areas
of
code
they
could
look
at
support
in
the
code
base
and
like
more
good,
first
issues
or
more
guidance.
D
C
I
feel
a
significant
significant
blocker
for
a
lot
of
people
is
the
fact
that,
in
order
to
start
contributing
to
node
is
10
to
30
minutes
journey,
in
which
you,
your
laptop,
becomes
a
little
stove.
C
D
C
Like
it's,
it's
just
like
if
you
need
to
run
zoom
on
your
machine
and
you
want
to
compile
node
at
the
same
time,
you
can't.
D
C
Yes,
it's
like
I,
if
you,
I
think,
the
biggest
barrier
for
contributors,
that's
the
biggest
barrier
for
contribution
rather
than
like.
I
think
people
can
live
with
the
review
like
they
review
stuff
and
so
on
and
so
forth.
But
you
know
every
single
time.
The
the
problem
is
every
single
time
they
came
back
to
it.
They
need
to
rebase
or
do
some
stuff,
and
then
they
are.
C
They
need
to
recompile
v8
and
then
it's
another
30
minutes
and
we
don't
really
tell
people
too
much
of
you
know
you
should
use
cc
cache
because
c
cache,
because
if,
if
you
don't
use
c
cache,
you're
completely
screwed
and
and
there
are
tools
to
automate
some
part
of
this
workflow,
even
like
there's
goma-
and
there
is
other
things
that
can
possibly
be
done
to
you
know
to
help
sustain
some
of
the
devs
and
it's
like
I
don't
know,
I
have
I'm
everything,
everything
else
it's
you
know
this
is
I'm
putting
it
something
meaningful
here
like
I
am.
D
C
No,
it's
because
otherwise
yeah
doing
it
for
my
laptop
will
be
unfeasible.
A
So,
right
and-
and
I
can
see
if
you've
got
somebody
who's
like
like
you've,
said
before
you
need
a
fair
amount
of
skills
to
be
able
to
contribute
and
stuff
and
if
you've
been,
we
might
have.
People
who
are
like
have
those
skills
are
willing
to
do
it,
but
like
an
hour,
30
minutes
waiting
means
that
they're
now
switched
on
to
something
else,
and
then
they
don't
come
back,
and
so
I
could
see
that
actually
having
a
significant.
A
C
It's
one
of
the
options
is
to
somehow
ship
some
of
the
pre-built,
some
pre-built
stuff
as
part
of
our
daily
ci,
or
something
like
that.
C
C
Reducing
and
improving
the
the
build
time
and
the
time
needed
for
to
like
okay,
let's
call
it
the
time
to
first
commit
or
the
time
to
commit.
A
C
D
A
A
Out
core
that
takes
a
bunch
of
time,
then
I
got
to
compile
the
whole
thing
that
could
take
on
a
small
machine
that
could
take
you
30
minutes
and
by
that
point
like,
if
you
tell
me,
I
have
to
do
an
hour
of
work
before
I
can
start
to
do
something,
and
I
got
an
hour
to
do
it
yeah
that
and
then
I
come
back.
I
don't
finish
it,
so
I
come
back
to
it
the
next
day.
C
A
C
And
we
can
only
need
to
support
like
three
four
platforms
like
it's,
not
that
we
need
to
support
all
of
them.
So
it's
you
know
it's
practically.
If
we
just
did
this
for
linux
and
mac,
we'll
get
a
huge
boost,
windows
would
be
a
huge
good
benefit
and
this
would
be
a
huge
boost.
I
think,
for
a
lot
of
people
that
you
know
wants
to
do
a
quick
collaboration.
There
are
other
ways
which
we
can
potentially
improve.
Some
stuff.
C
G
And
so
the
nice
thing
about,
if
you
do
a
docker
image,
you
can
load
a
well.
If
you
have
a
dev
container.json
file
in
the
repo
you
can
have,
you
can
just
load
that
as
your
work
spacing
code
spaces
like
you
can
load
the
docker
image
as
that,
so
it
makes
it
trivial
that
said
I've
built
node
on
both
the
basic
which
these
aren't
exposed.
G
G
C
So
it's
been,
the
date
is
done
once
by
the
the
machinery
and
then,
if
you
want
to
do
a
quick,
javascript
commit
okay
or
a
commit
that
does
not
touch
v8
or
any
other
of
the
c
plus
plus
dependencies.
C
G
C
Yeah,
but
it's
like
in
generic
case
yeah,
I
think,
there's
a
lot
of
ways
in
which
this
could
be
explored.
I
am
just
pointing
out
putting
it
out
to
the
into
the
into
the
other.
You
know
it's,
I
think,
if
we
want
to
so,
if
we
want
to
improve
the
to
create
a
easier
onboarding
path,
I
think
that
would
be
it.
A
Yeah,
okay,
so
from
our
just
looking
at
our
so
contribution
workflow
that
was
on
the
original
list,
and
you
know
back
to.
We
can
only
do
so
many
things.
It
sounds
like
we
have
one
good,
concrete
thing
that
we
could
say
is
the
priority.
Are
there
any
other
things
that
come
to
people's
minds
like
that?
That
would
make
a
you
know,
make
a
significant.
A
Okay,
I
think
well,
we
could
leave
that
so
now,
consensus
seeking
model
or
leadership
model.
Is
there
anything
on
those
fronts
that,
like
for
the
next
10
years,
like
do
people
find
those
frustrating?
I
guess
I
can.
I
know
that
there
is
definitely
the
answer
is
yes,
but
like
what
would
be
priorities?
What
what
could
we
change
or
whatever
that
would
affect
the
success
going
forward?.
A
G
I
mean,
I
think
it
ends
up
burning
people
out
as
they
try
to
contribute,
like
we've
seen
this
many
many
times
where
people
try
to
contribute
and
get
run
into
a
stone
wall
to
the
point
that
they
quit.
G
Yeah
that's
consistent
seeking
model.
I
think
leadership
model
does
play
into
that,
but
I
think
it's
largely
consensus
seeking
model.
D
D
Sorry,
I
was
just
going
to
kind
of
related
add
to
that.
We
often
see
a
problem
where
there
is
a
consensus,
can't
be
reached
in
a
particular
subsystem
and
that
will
get
elevated
to
the
tfc,
but
the
tsc
may
not
have
the
expertise
in
general
to
make
the
call
on
that
particular
subsystem.
So
it
has
to
go
back
to
the
people
who
know
the
subsystem
most.
It
seems
to
be
a
common
problem.
We
end
up.
D
A
C
Oh
yeah,
the
my
problem,
I
in
a
lot
of
cases,
so
the
tsc
as
a
group,
we
have
it's
a
neutrogena's
group
of
people
with
a
wide
range
of
skills.
C
Typically,
it's
very
rare
that
one
or
the
more
than
one
people
has
skills
on
one
area
of
node.
There
are,
there
are
overlaps,
but
you
know
it's.
We
got
essentially
a
few
people
that
have
skills
on
http
and
streams,
and
you
know
two
people.
In
there
we
got
a
couple
of
two
three
people
that
have
skills
on
be
on
the
build
on
build
and
releases.
C
We
don't
have
you
know
if
me
and
robert,
we
are
in
disagreement
on
some
features
that
we
need
to
get
into
streams.
There
is
really
nobody
else
to
break
that
tie,
and
this
is
the
case
for
a
lot
of
other
way.
We
had
an
issue
where
the
two
people
that
know
more
about
tls
were
arguing
about
the
tls
spec
on
an
issue
and
they
were
asking
well.
The
tsc
should
make
a
decision
here
and
just
like,
I
don't
have
a
month
to
study
the
dtl
aspect.
D
Yeah,
sorry,
just
to
add
that's
exactly
what
I've
seen
and
it's
because
the
code
base
isn't
simple
to
understand.
It
will
take
you
an
hour
or
so
of
reading
the
pr
to
even
get
enough
to
have
a
slight
opinion
and
sometimes
it'll
take
even
longer
than
that
and
people
just
don't
have
the
time
to
commit
to
learning
the
various
subsystems
where
it's
so
complicated.
A
So
what
could
we
change
to
make
that
better?
Like
yeah?
I
totally
identify
with
that
too.
It's
like
you
know.
You
know
some
of
your
areas.
You
have
a
good
opinion.
The
other
ones
you're,
like
kind
of
trust,
the
people
who
are
who
are
the
experts
in
that
way
and
then
otherwise,
it's
a
it's
a
good
effort
to
get
invested.
A
J
A
So
I
just
I
think
it's
worth
a
little
bit
like
because,
like
one
model
would
be,
is
as
tsc
members
we
commit
to
do
that
and
like
yes,
it
will
take
us
a
couple
hours,
but
the
challenge
I
think
today
is
I'd,
love
to
do
it
for
everyone,
but
I
don't
have
time
right.
So
I
pick
and
choose,
and
everybody
else
pick
and
chooses
and
what
we
the
problem,
I
kind
of
see,
is
we
don't
have
a
way
to
get
the
volunteer
to
do
it
in
a
timely
way,
but.
E
A
I'd
be
happy
to
commit
to
say
you
know
if
we
rotated
whenever
my
turn
came
up,
and
we
had
this
case,
I
would
jump
in
and
do
it
right
and
like
that's
a
model
like
that's
a
model
that
says
you
know
everybody
just
doing
it
on
their
own
figuring
out.
We
lead
to
this
well,
nobody
wants
to
because
they
know
that
it's
going
to
be
a
significant
amount
of
effort
to
do
it.
Every
time.
C
A
A
A
C
A
C
It's
to
be
honest:
if,
if
we
need
to
have
let's
talk,
let's
consider
modules.
Okay,
if
we
need
to
have
a
tie
breaker
for
modules,
yeah,
the
tyranny
says
a
thai
they.
I
love
the
concept
of
a
thai
cube,
but
that's
constantly
you
know
it's.
It
can
be
that
I
I'm
you
know.
We
can't
just
get
something
like
that
done.
What
was
the.
C
C
C
G
C
C
C
D
C
A
A
C
Yes,
yes,
of
course,
yes,
but
over
improve,
we
need
to
make
that
process
extremely
swift.
Okay,
so
to
the
point
of,
if
the
majority
of
the
code
owners
agrees,
everything
goes
through.
That's
you
know.
Simple
majority
of
code
owners
breaks
a
tie.
Okay,
yeah
right
like
something
something
like
like
something
like
that:
okay,
so,
okay,
I
don't
know
I'm
you
know
I'm
putting
it
out
loud,
but
it's.
A
I
think
that's
a
good
one
like
that.
That's
like
a
good
concrete
priority
under
the
consensus
seeking
model
and
like
I
think
the
next
10
group
could
come
up
with
a
proposal
right
because
sometimes
sometimes
concrete's
like
here's,
how
it
could
work
and
then
everybody
can,
you
know,
go
from
there
shoot
it
down
so
forth.
A
Is
I
think,
that's
the
in
terms
of
the
leadership
model
model,
so
you
know,
as
the
leadership
model,
that
we
have
today
fundamentally
causing
less
contribution
less.
You
know
affecting
the
success
as
we
go
forward
that
we
we
could
do
somehow
differently.
That
would
substantially
change
our
six.
Our
chances
for
success
and
level
of
success.
A
I
mean
today
our
tsc
model
has
been
like,
like
mateo
mentioned,
it's
almost
by
design
that
we
have
people
from
a
broad
range
of
areas,
because
we've
kind
of
in
some
cases
said
hey,
let's
bring
on
some
people,
because
they
know
these
areas
and
can
represent
that.
A
It's
also
very
much
intended,
like
the
the
governance
is
around
like
letting
the
collaborators
figure
things
out
and
the
tsc
gets
involved.
Only
when
the
you
know,
agreement
can't
be
reached
as
opposed
to
making
decisions
ahead
of
time
charting
the
path
that
kind
of
stuff,
so
that's
kind
of.
Like
the
you
know,
the
the
model
we've
used
and
and
adopted
over
the
over
the
years.
A
D
D
C
Let
me
speak
for
myself,
like
mostly
for
me
it
was.
I
cannot
take
another
meeting
in
term
of
workload
like
it
was
like
as
simple
as
either
that
or
the
good
dsc
meeting
it's
not
it's.
It's
just
amount
the
amount
of
effort
it's
just
time.
A
Along
those
those
lines
just
thinking
you
know,
the
the
current
tsc
meetings
have
a
certain
focus
which
is
like
we've
tagged,
the
things
which
are
the
exceptions,
the
ones
that
people
have
said
we
need
to
look
at.
You
know
we
could
change.
We
could
shift
the
content
of
those
meetings
to
be
alternating
between
its
tag.
What's
there
and
future
planning,
I
don't
know
if
that
makes
it
any
better
or
any
different
right
like
because
sometimes
we
don't
have
anything
on
the
agenda.
A
C
Essentially,
the
role
of
the
tsc
right
now
is
to
resolve
the
consensus
right
when
it
cannot
be
resolved.
Okay-
and
this
takes
some
significant
amount
of
time
if
we
can
delegate
a
part
of
that
activity
to
the
group
that
are
already
making
those
decisions
and
formalize
the
fact
that,
in
order
to
resolve
assist,
I
think
we
are
essentially
delegating
a
smaller
group
to
resolve
that
problem
that
can
free
up
other
resources
on
the
tsc
members.
C
I
don't
know
I
am
it's
a
a
lot
of
the
discussions
that
we
have
are
reacting
of
the
same
stuff
for
a
bit
of
direct.
We
have
issues
in
the
tc
agenda
that
has
been
going
on
for
months
and
agreed.
It's
I
don't
know
if
you're
making
any
good
progress
on
any
of
them,
because
we
cannot
even
ourselves
break
the
ties
like
we
cannot
break
the
like.
We
do
not
agree
between
the
tsc
members
and
we
don't
want
to
call
a
vote.
C
D
A
A
It
takes
more
time
and-
and
hopefully
you
know,
we
come
up
with
better
solutions,
but
sometimes
a
lesser
solution
would
be
better
if
it
was
faster.
So
that's
that
you
know
so
sometimes
it
might
be.
You
know
we
might
say
well,
sometimes
we'll
make
a
the
wrong
decision,
but
if
we
make
the
wrong
decision
faster
overall,
that
still
might
be
better
than
spending
yeah.
A
But
today
our
our
governance
is
really
around
like
we.
We
try
and
reach
consensus
and
get
input
versus
a
majority
wins
kind
of
thing
and
I'm
kind
of
like
for
me.
I
I'm
actually
not
so
worried
about
us
voting
faster
than
we
are,
but
I
I
don't
like
the
pure
majority
wins
part
where
people
like
if
we
have
50
of
the
people
at
a
meeting,
just
because
the
50
are
in
that
one
meeting
and
we
take
a
vote
that
doesn't
seem
quite
right,
because
the
other,
the
other
50
might
have
had
a
really
good
point.
A
C
You
know
from
my
point
of
view:
it's
like,
I
think
there
is
something
to
change
in
all
of
this.
I
think
that
message
that
we
can
send
back
to
the
tfc,
hey
tsc,
which
is
still
a
few
of
us-
are
that
would
overlap
here
in
this
meeting.
So
we
would
like
to
change
our
our
own
governance
to
solve
these
specific
problems,
and
can
we
okay?
C
H
A
A
Right,
like
that's,
that's
the
thing
that
maybe
we
think
coming
out
of
this.
This
discussion
is
like
if
we
were
to
change
something
on
the
leadership
model,
that
would
be
the
one
that
kind
of
maybe
maybe
since
we're
the
ones
who
are
interested
in
the
division
direction.
It's
it's
self-serving,
but,
like
that's,
the
thing
that
stood
out
to
us
is
like.
Maybe
we
should
be
more
involved
in
that.
A
What
I'd
suggest
is
that
we
try
and
close
out
on
this
maybe
give
somebody
people
one
last
chance
to
call
it
anything
specific
that
we
think
we
should
talk
about
this
and
then
use
the
last
minutes
to
put
together
like
our
next
steps-
and
you
know
what
we
want
to
see
coming
out
of
the
two.
The
two
sets
of
discussions
does
that
make
sense.
A
Yes,
okay,
so
any
last
call
for
next
ten
of
years
of
collaborators.
A
A
A
A
A
A
A
A
A
A
So
does
that
look
like
so
that's
our
our
our
watch
list
and
I
sorry
our
what
came
out
of
the
technical
priorities
at
the
very
highest
level
and
sort
of
next
steps
would
be
one
so
to
document
kind
of
like
we
have,
I
think,
for
the
you
know.
Like
you
see
the
constituencies,
we
had
the
titles,
we
explained
what
they
were,
then
what
the
people,
what
the
constituency
needed.
We
had
a
mapping
between
those.
A
A
That
sound
like
a
good
next
step,
or
do
we
need
to
have
some
discussion
like
an
intermediate
step
within
next,
the
next
tech
tech,
10
repo
to
work
on
the
list.
Or
what
do
we
think.
G
I
I
think
just
printing,
it
is
fine.
I
don't
think
we
need
to
introduce
more
work
around
it
like
we
relatively
have
this
done,
printing
it
in
and
like
reviewing
and
editing
if
we
need
to
there,
but
otherwise
just
going
ahead
and
writing
is
fine.
A
And
that'll
get
us
our
next
level
of
sort
of
collaborator
involvement
in
terms
of
like
hey
what
about
this
or
that
and
yeah?
Okay?
Who
all
would
like
to
be
involved
in
in
doing
that?
I'm
willing
to
volunteer
as
one
of
the
people.
A
Come
on
that
was
john
right,
yeah,
jean
right,
okay,
so
okay,
the
next
thing
would
be.
I
think
I
think
it
would
be
good
to
get
like
well.
What
do
you
think
I
don't
know
like?
Do
we
think
actually
getting
broader
ecosystem
input?
Like
you
know,
if
we
pr
that
in
and
then
we
did,
a
survey
like
we
did
for
the
constituencies,
would
that
make
sense.
G
A
You
know
some
broader
validation
that
we've
got
it
close
enough
to
write
that
there's
no
major
gaps
like,
for
example,
the
last
survey
helped
us
fill
in
a
couple
constituencies,
a
couple
of
needs
that
we
didn't
have
and
and
the
survey
the
other
thought
that
came
was
like.
We
could
do
a
survey
of
the
foundation
members
or
we
could
do
a
survey
of
companies
or
we
could
do
a
survey
of
individuals
like
that.
There
are
different
places.
We
could
go
and
try
and
get
that
validation
from
or.
G
G
C
I
would
not
take
it
perfectly
like
100
as
what
we
need
to
do,
but,
yes,
we
need
some
of
some
validation.
A
Okay,
so
some
maybe
we
can
just
say
like
plan
for
validation,
right
survey,.
C
C
A
C
A
A
Search,
you
know:
what
are
we
going
to
do?
We've
we've
said
that
suitable
types
are
are
important.
A
A
D
I
wondered
if
it
would
make
sense
when
we
go
back
to
our
weekly
every
two
weeks
meetings
having
a
session
on
each
of
them
to
get
a
bit
more
deep
dive.
A
D
A
Yeah:
okay,
that's
good
because
otherwise
it'd
be
take
us
a
while,
and
I
think
we
can
come
up
as
a
team
with
a
good
enough
explanation
of
what
these
mean
to
get
the
discussion
going
on
on
the
high
level.
So
yeah.
D
I
A
So
that
I've
decided
that
comment,
did
you
see
like
invite
other
working
groups
for
particular
sessions
or
go
to
their
meetings?
I
think
that
that
definitely
be.
We
can
find
a
group
that
already
might
have
an
interesting
in
that
area.
Let's
go
there
and
sounds
good
any
other.
Next
steps
on
the
technical
front
that
we
think.
A
A
Amount
just
because
of
time,
unless
people
have
anything
else
on
that
one,
I
suggest
we
move
on
to
the
next
10
years
or
sorry
for
the
collaborators.
G
I
think
opening
up
an
issue
or
discussion
about
the.
G
Pre-Builds
is
something
that
should
be
done.
I'm
happy
to
do
that
or
if
someone
else
wants
to
feel
absolutely
feel
free.
C
A
C
A
A
G
Pre-Builds
rebuilds
right,
I'm
I'm
happy
to
do
that.
I
gotta
drop
okay,
but
I'm
absolutely
happy
to
do
that
so
well.
I've
tagged
you
with
that.
Yo.
A
A
A
A
D
A
D
D
A
A
D
A
Right,
okay,
yeah
anything
with
them
like
now
or
in
the
future,
in
terms
of
updating
them
that
kind
of
yeah.
That's
that's
a
good
way
to
entry
point
that,
and
I
will
have
the
action
to
plan
this
into
one
of
those,
and
I
can
similarly
to
you
know,
michael.
A
A
A
A
A
So
I,
but
again
I
don't
want
to
be
the
blocker.
If
we've
got
to
volunteer
to
chair,
it
should
go
ahead
and
you
know
we've.
D
A
That
would
be
my
my
plan
is
to
start
driving
the
meetings
based
on
that
priority
list,
because
I
think
we've
closed
out.
You
know
the
initial
things
that
we
had
and
it'll
be
then
the
follow-ons
from.
A
D
In
that
case,
I'd
probably
suggest
deferring
until
we
have
that
list
pr
open
and
some
approvals
on
it.
So
we
know
where
to
go
from
there.
A
Okay,
so
thanks
for
everybody's
time
that
that
was
a
great
discussion,
I
think
we
came
out
with
some
tangible
things
I'll
take
the
action
to
kind
of
take
the
notes
that
were
written
and
put
them
into
a
form
where
we
get
them
into
issues
in
in
the
repo
like
the
next
10
repo
that
we
can
point
to,
and
I
look
forward
to
continuing
these
discussions
with
everybody.
I
think
that
was
very
useful.
Thank
you.