►
From YouTube: 2022-01-26-Node.js Technical Steering Committee meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
welcome
to
the
node.js
technical
steering
committee
meeting
for
january
26
2022
we'll
follow
the
agenda
that
was
posted
in
the
issue,
which
is
issue
1155
in
the
tse
repo.
Before
we
get
started,
does
anybody
have
any
announcements
they'd
like
to
share.
A
Maybe
I'll
share
the
one
announcement
that
tomorrow
is
the
next
10
mini
summit
on
modern
http
and
documentation.
The
goal
there
is
to
discuss.
You
know
we've
identified
and
documented
that
those
are
two
important
areas
to
the
future
success
of
node,
and
so
the
goal
in
that
mini
summit
is
to
go
through.
A
Each
of
those
and
figure
out,
you
know,
is
what
we
have
in
the
project,
what
we're
doing
the
project
good
enough
to
for
future
success,
or
are
there
some
things
that
we
should
be
working
on
and,
if
so
document
some
concrete
things
so
hoping
to
see
lots
of
the
tsc
members
there
and
you
know
other
people
from
the
community
who
are
interested
in
in
those
two
areas.
A
If
there
aren't
any
other
announcements,
I'll
move
on
to
cpc
and
board
meeting
updates
rich,
you
have
any
cpc
updates.
B
So
there
was
no
no
cpc
meeting
this
week,
so
nothing
from
the
meeting
necessarily,
but
there
is
something
I
I
don't
know
if
I
sent
it
to
the
tsum
analyst
or
if
I
added
it
to
the
issue
for
this
meeting.
But
there
is
a
cbc
effort
to
sort
of
establish
procedures
and
rules
and
guidelines
around
the
community
fund.
So
please
check
out
there
there's
a
issue
and
a
pull
request
in
the
in
the
cpc
repository.
A
And
his
focus
was
on
technical
strategy
for
the
foundation
and
we've
actually
opened
a
public
repo
now
called
tech
strategy
and
the
goal
there
is
to
kind
of
document
from
the
very
highest
level.
You
know
what
are
the
goals?
What
are
the
strategy
to
meet
those
goals?
And
then
what
do
we
actually
do
for
projects?
A
For
you
know,
individuals
for
companies
and
organizations
that
use
javascript
and
so
forth,
and
sort
of
go
down
and
document
that
strategy
with
links.
You
know,
maybe
not
with
all
the
information
there,
but
with
outside
links
and
stuff,
like
that,
so
still
very
much
a
work
in
progress,
but
if
you
have
an
interest
in
in
that
side
of
things,
there
are
things
you
think
the
foundation
should
be
doing
for
projects.
A
You
know
that
this
is
intended
to
document
what
we
want
to
move
towards,
not
necessarily
a
hundred
percent
where,
where
we're
at
so,
if
you
have
some
good
ideas
of
what
you
know,
the
foundation
could
be
doing
along
those
lines.
That's
a
place
to
provide
that
feedback
and
and
get
it.
You
know
documented
in
the
things
that
we
think
about
moving
forward.
A
On
the
board
meeting
front,
there's
a
meeting
tomorrow
friday
there's
nothing
that
I'm
aware
of
from
the
project
to
bring
to
the
board.
But
if
there's
anything
that
I'm
not
aware
of
just
let
me
know
so
if,
unless
there's
any
questions
on
that,
we
can
move
on
to
the
issues
that
were
tied
to
the
agenda.
A
The
first
one
is
managing
feature,
requests
number
four,
one,
one,
one
three
and
there's
also
related
pr41420.
A
You
know
so
looking
for
more,
you
know
involvement.
I
guess
there
to
either
help
define
what
we
should
do
to
manage
future
requests
or
agreement
that,
like
documenting
what
we
currently
do,
makes
sense.
I
think
the
main
changes
that
are
in
there
that
you
know
are
worth
commenting
or
thinking
about
are
like
what
what's
written
there
now
if
we
move
towards
it,
would
in
fact
result
in
us
closing
a
number
of
the
feature
requests
that
we
have
open.
A
Personally,
I
think
that's
the
right
thing
to
do
because,
like
after
they've
been
open
for
a
couple
number
of
years,
I'm
not
sure
that
they,
they
add
value,
and
I
think
that
it's
a
negative,
but
unless
there's
sort
of
questions
discussion,
I
think
this
is
mostly
like.
Please
go
in
and
participate
there
I
see.
Rich
did
have
his
hand
up,
though.
A
All
right,
so
I'm
gonna.
Unless
anybody
wants
to
raise
some
questions
or
start
a
discussion.
I'll
just
say:
please
engage
in
the
github
repo.
A
The
next
one
is
docs
clarification
around
real
world
risks
and
use
cases
of
vm
module.
This
is
four
zero.
Seven
one
eight.
C
A
A
A
B
A
A
A
Just
then
we
have
a
number
of
actions.
We
just
need
to
find
time
to
to
look
at
those
again.
A
The
next
one
is
invite
tc
members
in
the
google
calendar
for
events
for
meetings
number
113..
I
think
mary.
You
have
some
updates
on
that.
D
D
Can
you
hear
me
now
yeah?
Yes,
so
I
created
a
google
group
for
the
dsc
so
that
we
can
invite
that
google
group
the
reason
I'm
doing
a
google
group
instead
of
using
the
gohan
mailing
list.
Google
group
and
google
calendar
have
a
fairly
good
integration
like
if
a
new
member
is
added
to
the
google
group.
It
reflects
on
the
google
calendar.
If
there
are
changes
to
google
calendar,
they
easily
reflect
to
the
calendar
of
everyone
in
the
google
group.
D
And
since
we
are
already
using
a
google
product
for
calendar,
I
thought
it
made
sense
using
that
and
all
those
integration
points
do
not
work
with
the
with
our
mailing
list.
So
I'm
experimenting
with
that.
D
I
added
everyone
that
reacted
positively
to
my
comment
on
the
meeting
issue
to
the
google
group
and
if
everything
works,
if
there
are
no
complaints
or
concerns
about
how
it's
working
for
those
members,
I'm
gonna
propose
adding
the
google
group
as
one
of
the
steps
to
or
onboarding
of
parting
process,
and
if
that's
approved,
I
can
add
everyone
to
the
group,
and
hopefully
with
that
everyone
gets
an
invite
and
it's
easier
for
everyone
to
keep
in
sync
with
their
personal
work
and
tnc
calendars.
D
Could
we
have
gotten
an
invite?
Hopefully
I
just
did
it
like,
as
the
meeting
was
starting
so
okay,
so.
A
D
D
A
Okay,
anything
else
on
that
one
before
we
move
on.
A
E
A
E
Yeah,
so
I
finally
opened
a
draft
pr
for
that.
So
so
I'm
trying
something
here
and
I
hope
it's
gonna
work
so
because
we
we
don't
have
a
de
facto
tool
for
voting.
I
thought
why
not
create
it
one
myself
so
yeah,
I
don't
know
if
it's
gonna
end
up
working
for
us.
E
B
Did
you
check
what
find
inactive
tsc.mjs
does
in
that
votes
directory?
That's
modified
in
that
pull
request
to
make
sure
what
you're
doing
with
the
subdirectory
won't
conflict.
I
don't
think
it
will,
but
if
you
haven't
checked
I'm
going
to
go
check.
E
But
mary
has
her
hand
up.
The
deadline
would
be,
I
think,
two
weeks
or
you
know
before
that
if
everyone
has
voted
before.
D
A
E
Yes,
all
the
the
votes
are
encrypted
using
my
gpg
key
that
and
I
so
this
what
is
going
to
be
public.
So
all
the
votes
will
be
published
at
the
end,
but
if
we
want
in
the
future
to
have
private
votes,
we
could
also
trust
the
someone
in
the
tsc
to
keep
the
the
key
for
themselves
and-
and
just
you
know,
publish
the
result
and
not
the
votes.
B
So
there
there
are
kind
of
two
conversations
to
be
had
here.
One
is
whether
or
not
we
want
to
consider
like
standardizing
on
a
tool
like
this,
and
the
other
is,
can
we
just
get
started
with
the
boat
and
and
mary's
mary's
questions
and
implied
concerns
are
are
are
shared
by
me,
but
I'm
also
inclined
to
just
you
know.
Antoine
did
the
work
to
set
up
the
vote
and
I
would
like
to
start
voting,
so
I
just
wanted
to
verbalize
that,
because
this
this
this
decision
in
this
issue
has
been.
B
A
B
B
So
there
seems
to
be
a
lot
of
thinking,
but
unless
anybody
objects,
I
think
it
sounds
like
the
thing
that
I
proposed
and
michael
seconded
is
the
way
we're
going
to
go.
So
somebody
say
something
if
they
have
concerns
and
want
to
want
to
discuss
anything
or
suggest
a
different
path.
A
Okay
sounds
like
that's
the
way
we'll
go.
The
next
issue
on
the
agenda
is
the
next
10
minutes,
which
I
already
covered
in
the
in
the
announcement.
So
I
don't
think
we
have
anything
more
to
talk,
but
there
we
can
flip
over
to
our
strategic
initiatives
here.
E
No,
no,
no
date.
Okay,.
A
A
future
build
chain
anything
on
that
front
to
mary,
no
updates,
okay,
james,
anything
on
quick,
http,
3.
F
A
Okay
and
so
yeah,
I
think
that's
all
the
existing
active
strategic
initiatives
that
we
have
somebody
we
have
the
champion
here,
for
so
that's
it,
and
that
takes
us
to
the
end
of
the
agenda.
Is
there
anything
else
that
people
want
us
to
talk
about
before
we
close
up
for
this
week?.
D
I
added
an
item
yesterday
and
I
folks
had
time
to
look
at
it.
It's
about
how
to
handle
breaking
changes
that
are
not
intentional
when
they
land
on
releases.
D
So
we
end
up
in
a
limbo
where
we
don't
know
if
we
should
push
for
reverting
or
not,
and
I'm
aware
of
one
case
where
this
happened
and,
like
other
folks
are
aware
of
more
cases,
but
I
think
it's
something
that
we
need
to
discuss
and
formalize
what
the
process
is,
because
we
don't
have
anything
about
how
to
handle
unintended
breaking
changes
that
land
on
releases
we
only
have
for
when
they
land
on
master
and
yeah.
I
think
we
need
a
better
process
for
that,
both
to
both
from
a
preventative.
D
G
I
I
I
can't
remember
the
specifics,
but
I
I
do
remember
it
has
happened
a
couple
of
times,
especially
around
the
december
majors
going
out,
so
we
haven't
had
a
few
occasions
where
we've
done
assembler
major
and
then
had
to
do
a
point
release.
You
know
a
couple
of
a
day
or
two
later
and
really,
I
think
our
approach
in
the
at
least
in
the
release
team
so
far
has
been
to
try
and
weigh
up
how
quickly
have
we
caught
the
break.
So
if
it's
only
broken
in
a
release,
that's
just
gone
out.
G
The
release
team
is
reasonably,
we've
tended
to
just
you
know,
reverse
it
and
then
do
a
very
quick
point
release
to
revert
the
change.
The
trickier
question
is
if
that
break
happened,
but
it
hasn't
been
noticed,
and
now
we
have
several
releases.
You
know
several
either
patch
or
some
minor
releases
down
in
the
release
line,
and
then
the
question
is
who
is
going
to
be
more
broken,
the
the
people
that
were
broken
by
the
original
change
that
we
didn't
expect
to
happen,
or
people
that
have
now
using
the
changed
behavior
that
will
be
broken.
G
If
we
reverse
it
back,
and
I
don't
know
if
there
is
going
to
be
an
easy
way
to
codify
what
we
would
do
without
assessing
the
impact.
D
So
I
agree
it's
going
to
be
a
case-by-case
thing,
but
I
think
we
can
list
some
options,
at
least
on
our
guidelines,
for
example,
in
a
situation
where
there
is
a
broken
change
and
we
don't
notice
for
a
few
releases
when
it's
caught,
like
maybe
the
documentation
is
out
of
date,
or
maybe
it's
didn't
show
up
on
the
changelog
because
of
a
bug
on
the
tooling.
D
Even
if
we
decide
that
that
breaking
change
is
going
to
remain,
and
maybe
we
can
also
because
that's
probably
going
to
be
detected
by
some
open
source
project.
Although
not
necessarily,
maybe
you
can
have
a
process
or
gate
guideline
that
if
a
project
detects
a
breaking
change
that
went
out
by
accident
on
a
minor
patch
release
that
we
can
add
that
project
to
canary
in
the
gold,
mine
or
something.
C
I
think
that
we
should
maybe-
and
like
maybe
mayor
you
can
help
us
with
the
like
the
releasers,
but
like
come
up
with
scenarios
that
are
possible
or
that
we've
seen
before
and
then
because
all
of
these
sound
like
they
have
some
combination
of
code
and
or
communication
that
needs
to
be
followed
up
with,
and
then
so
we
say:
okay
like
these
are
all
the
scenarios
that
we're
equipped
to
handle,
and
then
we
just
like
put
explicit
steps
the
same
way
we
have
like
specific.
C
You
know,
steps
that
we
have
for
handling
different
things.
You
know
in
the
node
project
we
just
have.
Okay,
like
these
are
all
of
the
scenarios
that
we
handle
in
the
case
of
like
an
incident.
We
just
like
treat
it
like
an
incident
and
then
follow
those
specific
steps
and
then
follow
like
these
specific
communications
guidelines
stuff.
So
that
means
like
tweeting
from
the
node
twitter
account
saying
hey
like
this.
This
release,
like
don't
upgrade
it.
You
know
we
have
like
an
issue
with
it
or
whatever.
C
If
it's
been
too
long
and
we
can't
put
a
patch
out-
so
I
think,
there's
like
probably
a
little
work
to
be
done
on
the
release
team
to
like
figure
out
what
those
steps
are
and
what
those
scenarios
are
too.
A
Yeah,
I
think
that
would
be
really
useful
in,
like
you
know,
if
there
was
like
it'll
get
harder
and
harder,
but,
like
you
know
you
we
could
say
like.
If
it's
within
a
week
of
the
release
going
out,
then
our
processes-
we
just
revert
it
right.
Then
you
could
document
that,
like
what
you
said,
here's
the
way
we
would
communicate
that
out
and
having
that
playbook,
I
think,
would
be,
would
be
very
useful.
D
Yeah,
I
I
think
one
week
is
probably
like
a
long
time
does.
It
have
to
be
something
in
the
lines
of
48
hours
probably
depends
on
the
code
path,
but
again
I
don't
think
we
have.
We
need
to
have
a
super
strict
process
here,
but
at
the
very
least
guidelines
with
suggestions
of
what
can
be
done
on
this
kind
of
situation.
D
Another
issue
that
is
kind
of
related,
we
don't
usually
do
breaking
changes
like
we,
don't
usually
break
apis
without
deprecating
them,
first
or
at
least
remove
apis.
So
there
is
also
a
question
of
how
the
progression
cycle
fits
into
this.
D
Into
a
unintended
breaking
change
like
how
do
we
fire
the
api
to
be
deprecated
for
a
major
in
the
case,
assuming
that
we
revert
something?
Could
we
force
it
to
be
deprecated
during
that
major,
and
could
one
major
be
enough,
or
would
we
wait
for
two
majors
before
actually
landing?
Whatever
change
was
made.
A
D
Yeah,
I
think
a
next
step,
then,
is
for
us
to
collect
cases
in
the
past
where
we
had
to
handle
unintended
breaking
changes
and
see
how
we
handle
them
and
work
in
conjunction
with
the
release
team
to
come
up
with
some
guidelines
about
how
to
handle
it,
so
that
we
can
include
that
in
the
collaborators
guidelines.
B
I
guess
I'd
want
to
know
if
there's
an
outcome
of
this
conversation,
that
mary
was
hoping
for,
that
hasn't
hasn't
happened
yet.
D
Now,
I
think,
that's
a
long
term
thing
that
we
have
to
work
on
and
not
like.
As
I
said
in
the
issue,
I
don't
think
that
dangling
the
discussion
with
the
issue
that
I
use
as
an
example
is
productive,
and
we
should
think
more
of
a
bigger
picture
here
and
just
agreeing
that
we
have
to
talk
about.
It
is
enough
for
me.
I
think,
okay,
step.
A
A
Okay,
any
other
things
or
any
other
topics.
People
want
to
discuss
before
we
close
out
the
meeting
for
today.
A
If
not
well,
thanks
for
everybody's
time
and
thanks
everybody
who
made
the
meeting
as
well
as
those
who've
been
watching
on
the
live
stream,
and
we
will
see
everybody
next
time
all
right,
bye,
all
right.