►
Description
B
C
C
C
B
Okay,
let's
move
on
to
the
agenda
items
generated
from
the
agenda
tag
so
starting
out
with
the
tracking
issue
for
runtime
deprecation,
a
buffer,
constructor
and
I.
Think
tied
was
that
we
should
have
this
discussion
on
the
next
item,
which
has
also
do
the
deprecation
warning
aside,
node
modules,
because
that's
tightly
related.
D
So
the
second
issue-
the
only
thing
we
need
to
talk
about
there
is
we
need
to
have.
We
need
vote
on
whether
it's
gonna
land
or
not,
and
hopefully
most
of
us
have
looked
at
it
already
and
made
made
a
mayday
formed
an
opinion
so
I'm
opening
it
right
now
and
it's
gonna
really
so
there
we
go
so
it
looks.
I
mean
I'm,
assuming
that
that
anybody
who
on
TSC,
who
has
approved
it
would
advocate
for
it
would
vote
for
it.
That
might
not
be
a
great
assumption
to
make.
D
A
D
A
D
F
B
So
yeah
I
think
we'll
close
on
that
one.
Let's
move
on
to
the
next
one,
which
is
crypto,
adds
support
for
AES
CCM.
It's
number
one,
eight
one,
three,
eight
it's
on
the
agenda
because
we
need
additional
approvers
and
again
because
we
have
time
this
is
running
out.
It
was
good
to
bring
that
to
people's
attention.
Just
opening
it
up
myself
to
see
if
we've
got
those
additional
provers
yet
github
is
taking
I've
got
the
unicorn
telling
me
it's
taking
way
too
long
to
load
I.
B
Don't
know
if
anybody
else,
maybe
it's
my
geo-
is
anybody
else
having
better
luck.
Oh
there
we
go
Atlanta,
it
loaded
I
still
see
we
have
James
and
shigeki
who
have
approved
it
and
been,
but
I
think
the
ask
at
the
bottom
was
an
additional
reviewer
from
the
TSC,
preferably
somebody
who's
been
active
on
the
crypto
side.
Right,
yes,.
D
D
B
G
D
F
H
F
D
B
B
C
C
B
B
B
A
Hi,
so
I
can
give
an
update
on
a
few
things
from
last
time.
So
in
the
public
session
of
the
board,
we
discussed
three
topics
program.
An
update
on
the
subcommittee
and
interactive
with
people
on
this
call
be
interested
in
immediate
redoing.
That
kind
of
update
on
the
mentorship
program
double
TLC
right
now.
A
The
Membership
Committee
quick
update
some
of
the
decisions.
These
are
all
mostly
found
from
their
documentation
from
reviewing
their
their
meetings.
They're,
currently
starting
with
node
slackers,
using
for
communicate
using
used
for
communication
between
people.
The
initial
surveys
had
gone
out
with
sign
up
link
for
mentees
and
mentors,
and
this
Friday
will
actually
be
the
first
being
of
mentors
who
have
signed
up.
If
you
look
on
issue
number
14,
there's
a
little
more
information
about
that
and
the
links
to
sign
up
are,
on
the
main,
read
me
a
little
bit
about
the
process.
A
So,
for
the
sake
of
through
this,
some
definitions,
leader,
is
a
member
of
the
mentorship
program
responsible
for
arranging
and
participating,
meaning
between
a
matched
pair,
a
matches.
A
selective
error
of
a
mentor
and
mentee
participants
are
a
mentor
or
a
mentee
in
the
program.
A
mentors
and
nodejs
mentor,
an
dementias
and
ogs
mentee,
mentors
and
mentees
are
matched
and
there's
a
three-way
kickoff
meeting
to
introduce
set
goals
and
expectations
between
a
leader
from
the
project,
the
mentor
and
the
mentee
the
project.
In
this
case,
being
the
mentorship
project.
A
The
process
is
expected
to
iterate
as
they
go
through
and
see.
What's
successful
and
not
successful
for
meetings,
note
slackers
will
be
used
as
a
communication
tool
between
mentors
and
mentees,
but
that
is
up
for
discussion
and
people
can
away
from
it.
It
doesn't
scale.
I
also
think
it
won't
be
used
in
lieu
of
other
communication
means
so
like
we
use
IRC
for
a
lot
of
the
TSC
and
development
and
I.
Don't
imagine
that
we
would
be
moving
that
the
mentorship
program
is
expected
to
run
like
a
mentor.
A
Mentee
pair
would
work
together
for
six
months.
The
expectations
for
part
four
participants
is
all
found
in
the
readme.
Put
some
highlights
that
are
worth
knowing
is
that
the
expectations
are
they
meet
for
about
a
minimum
of
an
hour
every
month
that
the
mentor
would
offer
mentees
ongoing
support
with
poor
requests
and
issues?
It
is
expected
to
be
mentee,
driven
and
mentored
guided.
So
that
means
that
the
mentees
were
coming
into.
A
The
program
are
expected
to
identify
career
goals,
set
one
to
three
goals,
set
their
process
and
the
mentor
would
work
as
a
facilitator
of
helping
them
through
that
there's
an
expectation
of
language
diversity
in
time
zones.
So
the
program
is
trying
to
pair
people
with
preferred
languages
with
each
other,
as
well
as
in
time
zones
that
makes
sense
to
be
able
to
meet.
The
one
note
that
I
do
have
from
them
is
that
they
currently
have
not
defined
any
sort
of
process
for
a
mentee
and
mentor
that
don't
work
out.
A
A
There
was
an
update
on
the
leadership
sub-community
committee,
nothing
super
in-depth,
but
primarily
around
hey.
You
know
what
is
going
on
who's
participating
in
the
meeting
and
what
the
current
stuff
is
going
on,
specifically
around
evaluating
the
individual
membership
program
and
trying
to
figure
out
what
a
future
for
that
program
looks
like
and
identifying.
You
know
what
have
been
some
of
the
problems
with
success.
Currently
you
know,
should
there
be
a
program,
what
should
be
the
program
and
that
kind
of
fun
stuff?
A
There
was
also
an
update
on
jeaious,
interactive
basic
update
on
timing
and
papers
going
out,
but
nothing
of
particular
note.
Just
a
general
update.
The
board
meeting
did
not
run
for
the
entire
time.
It
was
fairly
uneventful.
That's
everything
for
the
update
for
now.
I
expect
an
email
coming
momentarily
with
you
know
the
updating
text,
okay,.
B
Thank
you,
okay,
I'm,
going
to
well
on
the
strategic
initiatives
so
I'll
quickly,
just
mention
any
PI
backports
for
8
X,
+,
6
X
are
in
progress
and
we're
also
looking
to
ramp
up
efforts
on
documentation
for
the
node
add-on
API.
We
have
good
documentation
for
the
core
API,
but
that
the
module
still
needs
some
work
and
Nicola
who's
on
the
n.
Api
team
has
been
doing
a
lot
of
good
work,
actually
doing
ports
and
providing
them
to
module
owner.
So
he's
probably
got
like
10
of
those
on
the
go.
B
H
A
So
yesterday
we
had
an
online
module
summit.
It
was
really
fantastic.
It
ran
for
eight
hours
and
had
eight
different
presentations
and
open
conference
discussions
around
a
number
of
topics
from
user
land
to
standards
to
a
history
to
the
future.
It
was
really
great
to
see
everyone
involved.
We
had
between
15
and
17
members
of
the
modules
team
who
are
on
the
call
throughout
the
whole
day
with
a
I.
A
Don't
have
a
full
count
of
all
the
different
people
who
came,
but
when
you
add
up,
everyone
is
definitely
more
than
quorum,
which,
for
that
group
is
like
22.
People
need
to
have
quorum
they're.
All
the
videos
have
actually
already
been
edited
and
put
on
YouTube.
So
if
you
go
to
the
nodejs
youtube
channel,
you
can
see
a
playlist
for
it.
A
We
have
another
meeting
next
week
where
we're
going
to
continue
to
drive
in
dive
into
huge
cases.
What
are
the
things
that
we've
been
exploring
in
the
team,
which
has
been
really
successful,
is
ways
of
handling
conversations
up
to
now,
we've
primarily
been
using.
You
know
the
hand-raising
stuff
inside
of
zoom,
but
there's
a
tc39
tool
that
gives
a
little
bit
more
granularity
as
far
as
participating
in
discussion.
So
we
may
try
experimenting
with
that
in
the
next
meeting.
A
I
think
these
tools
are
really
useful
for
us
to
have
it
in
our
tool
belt
for
more
contentious
discussion,
I
think
in
the
TSC.
This
is
not
something
that
we've
done
really
had
to
worry
about,
but
for
more
public
working
groups,
this
could
be
a
good
kind
of
precedent.
It's
also
really
good
to
make
sure
you
know.
I
myself
have
my
brain
directly
connected
to
my
mouth.
So
I
can
just
start
talking
without
even
thinking
but
I
do
know.
A
There's
a
lot
of
people
who
like
to
take
more
time
to
be
thoughtful
about
what
they're
doing
or
have
ideas
as
well.
Someone's
talking
I
want
to
be
able
to
raise
an
issue
and
revisit
it,
so
these
tools
can
really
help
people
who
are
active
in
conversations
to
get
more
involved,
I,
which
is
raising
and
yeah.
D
A
B
I
Well,
update
might
be
a
strong
word.
I'm
gonna
share
my
screen.
If
that's
okay
for
a
little
bit
well,
it's
kind
of
more
the
lack
of
update
that
we're
gonna
be
talking
about.
So
it's
a
big
question
mark
so
there's
this
older
proposal
that's
been
around
for
three
years
bones
it's
similar
to
domains,
but
we're
gonna
kind
of
just
go
over
why
things
have
changed
a
little
bit
in
history.
So
what
are
there
a
way
to
create
async
context?
You
can
store
data
on
them,
they're
hooks
for
entering
the
context
and
domains.
I
I
I
So
it's
a
subset
of
what
domains
were
intended
to
be,
but
we
have
some
interesting
stuff
going
on
here.
We
don't
actually
have
official
documentation.
That
note
is
blocking
this
there's
like
one
issue
in
multiple
attempts
to
bring
it
up
in
various
places,
but
it's
never
actually
been
discussed
at
a
meeting
so
I'm
here
to
at
least
start
the
discussion.
I
We
have
a
much
clearer
process
with
the
TSE
than
two
years
ago,
which
is
around
the
time
that
people
were
actively
discussing
zones.
I've
tried
to
get
a
hold
of
Trevor
Norris.
He
and
myself
are
the
main
people
who
are
against
zones,
but
I
haven't
had
success
and
getting
a
hold
of
him
over
the
course
of
a
couple
months.
C
I
I
Okay,
that's
a
different
window.
I
had
it
opened
up
in
two
windows,
so
yeah
I
was
mostly
talking
about
these
slides,
where
it's
just
these
are
what
people
can
do
promises.
You
know
the
same
stuff.
I
said
this
is
slightly
reordered.
You
can
get
stuff,
but
I,
don't
even
technically
know.
If
note
is
blocking
this
because
we
don't
have
docks,
promises
are
being
adopted
or
adopted
already.
They
introduced
some
of
the
air
swallowing
of
the
domains
postmortem.
So
that's
not
great.
It
also
has
promises
with
their
error.
I
Propagation
mechanisms
and
async
functions
make
it
so
you
don't
actually
use
promise
api's
and
see
where
the
error
aggregation
is
changing
so
kind
of
why
I
want
to
revisit.
This
is
because
promises
kind
of
give
us
the
problems
of
the
domain
postmortem,
even
if
we
don't
have
domains
so
the
historical
conflict
that
was
in
the
issue
with
me
and
Trevor
Norris.
Is
we
didn't
like
that?
Changing
the
storage
for
async
contexts
to
also
change
air
handling
in
zones?
It's
a
little
more
limited
than
domains.
I
It
only
happens
when
you
call
zone
dot
run,
so
you
can't
like
dot,
enter
and
never
dot
exit
you.
You
can't
pollute
your
async
context
as
easily
and
you
can't
swap
your
parent
at
any
given
time.
So
zones
are
basically
more
limited,
so
why
were
we
so
angry
in
that
issue?
Thread
there's
a
severe
fear,
two
years
ago
of
reproducing
the
domains
post-mortem,
because
they're
trivial
to
implement
using
domains,
I
even
implemented
them.
It's
like
a
hundred
lines
of
code,
but
it
can
be
compressed
down
to
like
eleven
lines
of
code.
I
If
you
take
out
comments
and
things,
but
the
the
main
thing
here
is
part
of
the
domains.
Post
mortem
is
the
problem
with
error
propagation
and
we're
starting
to
see
that
more
common.
Just
because
promises
exist
not
saying
we
can
stop
people
using
promises.
I
think
I
think
that
ship
sailed,
but
people
are
starting
to
do
things
in
strange
ways.
So.
I
I
So
the
basic
thing
is:
we
have
the
error
problem
of
domains,
postmortem
already
it's
it's
come
back
to
haunt
us,
and
people
have
no
guidance
by
the
language
or
environment,
and
there
are
no
hooks
into
the
language
or
environment
to
help
people
kind
of
deal
with
these
problems.
So,
instead
of
doing
that,
they're
just
making
it
so
errors
are
swallowed,
and
that
seems
a
little
weird,
but
it
works
for
some
people.
I
The
other
fear,
mainly
in
post-mortem,
was
performance,
but
if
you've
looked
at
the
benchmarks
and
discussions
about
async
hooks,
they
also
have
this
performance
concerns.
I'm,
not
sure
that
zone
czar
in
a
different
category
here,
so
people
might
be
able
to
prove
me
wrong,
but
basic
folks
also
have
a
performance
problem.
It's
so,
even
though
we're
comparing
zones
to
domains
other
api's
are
facing
similar
issues.
I
So
what
what
what
is
zones
blocked
on?
They
want
to
add
error
handling
to
this,
and
that's
where
we
stop
them
so
they're
blocked
on
the
fear
of
domains,
basically
and
finally,
I
just
wanted
to
give
like
a
little
example
for
anybody
who
has
questions
and
stuff.
We
can
go
over
the
example
if
need
be,
but
if
we
get
nothing
else,
I'd
like
official
documentation
that
no,
we
will
never
allow
this.
But
the
problem
seemed
to
exist
today,
even
without
zones
existing.
I
D
K
So
so
to
whoever
talked
before
Ali
talked
I
think
I
was
rich,
so
we
we
are
blocking
this
because
we
actually
need
to
implement
this
on
the
in
our
API
is
for
it
to
do
anything.
So
if
it
lands
and
we
don't
implement
it,
then
you
don't
get
it
that,
or
at
least
that
was
my
understanding
of
it.
Correct
me
if
I'm
wrong,
I,
think
all
of
our
API
endpoints
need
to
implement
this.
I
K
I
I
I
J
So
I
was
so
much
involved
in
the
original
discussions,
although
Dominic
and
mishko
on
that
little
driving
this.
So
my
understanding
was
that
at
some
point
they
lost
motivation
so
it
because
there
was
pushed
from
Trevor
and
Bradley.
So
it's
not
that
the
TAC
has
blocked
it,
but
the
general
perception
was
that
there's
people
in
the
node
community
that
are
significantly
pushing
against
it
and
TAC
is
likely
to
have
a
similar
perspective.
J
C
Thank
you
so,
first
of
all
the
major
problem
with
us
in
cooks
today
and
domains
right
now,
it's
that
it's
a
hover
head
exactly
with
promises,
okay
and
enabling
zones
as
a
language
construct,
might
add
to
have
that
enable
all
the
time.
Well
at
this
point,
if
you
want
to
not
have
that,
you
don't
want
to
add
any
APM
problem,
you
do
not
have
to
take
the
hit
so
as
long
as
the
mechanism
is
not
enabled
by
default,
it's
possibly
to
reason
about
that.
C
Okay,
it
doesn't
say,
I've
never
looked
into
it
really,
so
I
am
I'm
willing
to
go
through
it.
If,
if
we
want
to
talk
to
talk
about
it
more,
the
second
problem
about
the
second
problem
or
problem,
but
what
I've
seen
this
happening
in
real
life
is
there
is
a
strong
need
for
standardize,
a
synchronous,
conscious
tracking
system
and.
C
Being
that
a
CLS
hooked
solution
or
whatever
contact
local
storage,
whatever
it
is,
is
very
much
in
using
the
community
in
the
node
community,
not
that
not
hundred
percent
but
sizable
enough
chunk
of
the
ecosystem.
Does
this
at
the
moment,
which
means
right
now
it
will
use
the
sync
books
anyway,
okay,
so
my
main
concern
is
only
if
so.
One
thing
is
error,
handling
which
needs
to
be
looked
into
it
very
closely,
and
it's
a
long
discussion
to
avoid
the
domains.
C
Post-Mortem
more
or
less,
and
the
second
bit
is
performance
and
being
able
to
actually
not
add
these
enable
all
the
time,
because
if
it's
enable
all
the
time,
that's
not
that's
very
much
a
good,
but
we
are
basically,
we
are
going
to
slow
us
down
a
significant
chunk
of
our
ecosystem,
meaning,
for
example,
everybody
that
use
webpack
or
all
the
CLE.
Cli
too,
will
have
a
hit
because
of
this
just
by
having
this
feature
here,
okay
in
the
in
the
language,
that's
by
enabling
a
singles.
C
So
there
is
a
lot
of
use
cases
when
the
heat
of
that
is
not
sustainable.
So
that's
more
or
less
my
my
take
but
I'm
very
willing
to
talk
about
it
so
feel
free
to
pull
me
in
a
separate
discussion
and
we
can
even
put
to
type
some
code
so
I'm
not
I'm,
not
saying
it's,
this
good
or
bad
okay,
I'm
just
saying
we
should
be
sure
you
should
probably
look
into
it.
If
it's
blocked
by
node,
we
should
at
least
either
have
a
formal
saying
yes
or
no.
J
Talks
are
happen
that
are
so
I
think
without
a
language
level
construct
for
for
talking
about
context.
That
is
a
prompt
today
and
we
are
seeing
I
would
argue
a
broken
language
because
we
don't
have
early
ýstanbul
context,
specific
semantics
promises
are
being
used
and
issues
that
Bradley
pointed
out
are
real
issues,
so
I
think
the
performance
concerns
are
valid,
but
also
at
the
same
time,
I
think
there's.
J
There
is
the
need
of
proper
being
able
to
write
week,
one
note
and
JavaScript
to
be
a
platform
where
people
can
write
and
reason
about
their
code
for
and
and
and
the
via
T
is
working
on.
Releasing
the
order
of
overhead
of
promise
sucks
it
soon,
I,
don't
know
if
they'll
ever
get
it
to
be
free,
but
perhaps
I
it's
unavoidable.
If
we
want
to
be
because
people
to
be
productive
and
be
able
to
reason
about
the
program's.
D
B
Think
that's
a
good
idea
because
we're
we
don't
have
too
much
more
time.
Why
one
other
thing
I
would
Bradley?
Is
there
somebody
externally
pushing
this
like
it?
Has
they've
come
back
to
you
and
said:
hey
we'd
like
to
move
it
forward,
or
is
it
just
that
you
said
we'd
like
to
move
it
forward
and
just
wondering
what
the
the
trigger
was.
I
I
That,
or
is
it
it
would
make
their
code,
presumably
less
buggy
and
have
a
standard
held
up
to.
It
would
also
give
us
well-defined
places
that
we
can
help
debug
things,
because
when
we
encounter
these
problems,
we
have
to
go
and
we
have
to
learn
custom
control
flow
for
air
handling
in
different
libraries,
okay,.
B
I
I
D
I,
don't
I,
don't
know
that
we're
blocking
it
at
this
point,
I
mean
I,
we're
not
committed
to
imply.
You
said
if
we
have
to
implement
it
in
our
own
api's
to
make
it
you
know,
work
usable
and
note,
then
we're
not
committed
to
it.
Obviously,
I,
don't
I,
don't
think
we're
walking
here.
I
think
it's
like
bitten,
at
least
certainly
from
my
perspective,
I
think.
B
That's
exactly
the
way
I'd
characterize
it,
so
it's
we're
not
gonna
necessarily
do
anything,
but
we're
not
saying
we're.
Not
nobody
saying
can
we
can
you
know
we
want
to
move
it
forward
and
we're
saying
no
I
mean
it
sounds
like
what
what
they're
the
real
ants
you
know,
the
real
impetus
is
you're,
seeing
real
problems
in
production
and
it's
like
we
should
be
thinking
about
a
solution
and
we're
not
James.
B
I
F
F
We
probably
will
not
be
able
to
refine
our
opinion
of
this
until
there's
an
update,
so
there's
a
Q
know
until
there's
actual
progress
on
it.
I
think
probably
the
the
logical
next
step
is
to
you
know,
go
back
to
the
champions
they
want
to
move
forward
and
what
changes
they
they
want
to
make,
and
then
we
start
a
dialogue
from
there.
F
F
B
K
Either
interject
with
it
so
I
think
I
think
we
leave
at
maybe
MIT
it
sounded
like
Mateo
had
like
the
same
sort
of
concern
that
I
did
so
I
think
like
if
it
can't,
if
it
can't
be
showing
that
it
is
optimizable,
then
I
think
we
might
actually
be
blocking
it.
But
I,
don't
think
that's
really
the
case,
but
nothing
has
been
shown
that
it
nothing
has
been
shown
that
it
is
optimizable
leader,
Amos.
I
D
A
B
A
A
Essentially,
the
request
was
that
we
just
halt
new
semver
miners
from
landing
until
the
team
has
had
a
chance
to
discuss
them,
but
that
any
patches
or
fixes
can
land
the
main
idea
behind
it.
Being
that
we
don't
want
to
introduce
any
new
mechanisms
into
it
into
the
modules
implementation
that
could
potentially
get
people
adopting
it
and
create
problems.
If
we
ever
need
to
change
it.
So,
like
a
really
good
example,
would
be.
We
have
consensus
in
the
working
group
right
now
to
not
move
forward
on
the
inline
package.
A
Json
moves
per
request,
which
introduces
a
whole
new
mechanism
to
resolution,
but
there
was
consensus
that
we
should
move
forward
on
destructuring
for
era's
named
exports
for
poor
modules.
So
I
just
wanted
to
see
if
anyone
from
the
team
had
objections
to
to
moving
forward
with
that.
Just
so
I
can
close
the
loop
with
the
team
so.
A
I
think
for
what
it's
worth
like,
we
have
enough
stakeholders
inside
of
the
team
that
anyone
could
just
block
it.
So
I,
don't
think
this
needs
to
be
anything
formal
I.
Just
this
was
the
recommendation
and
I
just
wanted
to
know.
If
anyone
from
our
steering
committee
has
a
problem
with
that
recommendation,
I
don't
think
we
need
anything.
Formal
members,
like
myself
of
the
team,
are
perfectly
capable
of
implementing
this
anyways
I.
Just
don't
want
us
moving
forward
on
this.
A
D
B
B
B
B
K
B
Okay,
so
if
we
have
no
other
things
and
the
question
answers
upcoming
meetings,
you
can
consult
the
note
gist
calendar
I.
Think
I,
don't
know
if
it's
worth
going
through,
but
you
know:
there's
lots
of
different
things
on
the
calendar.
I'd
really
recommend
actually
just
going
to
the
calendar
and
checking
it
out
to
keep
up
to
date.
Are
there
any
other
things
that
people
think
we
should
discuss
before
we
close
for
today.