►
From YouTube: 2022-05-18-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
I
guess
it's
worth
mentioning:
openjs
world
is
coming
up
in
a
few
weeks,
so
we're
gonna
have
a
collaborator
summit.
There
there's
some
great
sessions
that
have
been
suggested
and
there's
some
planning
going
around
in
terms
of
the
like
the
node
sessions
and
layout
and
stuff
like
that.
So
if
you're
interested
you
can
head
over
to
the
opengs
summit,
repo
still
room,
I
think,
to
propose
new
sessions
and
we
hope
to
see
a
bunch
of
collaborators
there
to
discuss
things.
A
I
guess
moving
on
to
the
cpc
and
board
meeting
updates
rich
anything
on
the
cpc
front.
B
There's
a
working
meeting
this
week
about
code
of
conduct,
update
type
things.
If
I
understand
correctly,
I
did
not
attend,
they
did
record
it.
So
I'll
watch
it
or
read
the
minutes
when
I
get
a
chance,
but
I
don't
think
there's
anything
announcement
worthy.
If
you
were
there
and
you
have
a
contrary
opinion,
please,
please
feel
free
to
correct
me.
A
Okay,
so
the
first
one
on
the
list
is
revert:
the
change
of
network
interfaces
from
spring
to
integer
number
4305.
I
think,
as
I
understand,
and
the
second
one
which
is
related
to
I
guess,
four,
three,
oh
four,
one
one's,
probably
the
yeah
once
the
pull
request
one's
the
the
pr.
I
think
that
this
was
discussed
and
agreed
last
time
right.
C
Yeah,
that's
correct,
the
the
pr
is
is
open
and
I
guess
we
can
just
use
the
review
process
too.
We
need
to
discuss
it
here.
A
Right,
okay,
there's
so
yeah,
there's
nothing
to
discuss.
Should
we
just
take
those
two
off
of
the
agenda
like
remove
the
agenda
tag.
A
Okay,
I'll
do
that,
if
that's
so
nobody's
concerned,
okay,
moving
on
to
the
next
one
number
42981,
this
is
one
that
I
opened
about
auto
closing
stale
prs.
You
know
I.
I
took
a
look
in
our
last
sort
of
triage
day
and
we've
got
at
that
time.
We
had
340
open,
prs
117,
which
are
older
than
a
year,
and
you
know
my
thinking
is
as
a
unlike
an
issue.
An
issue
could
be
open
and
you
know
it
could
be
valid
forever.
A
If
we
don't
fix
it,
a
pr
is
very
likely
that
after
a
year,
it's
going
to
be
stable
out
of
date,
especially
if
there's
no
comments
or
activity
on
it.
So
you
know
my
proposal
is.
A
We
should
look
at
doing
something
where
we
have
the
the
bot
fine
prs,
which
are
older
than
a
year
and
haven't
been
commented
on
in
six
months,
and
I'm,
like
you
know,
99
sure
that
most
of
those
will
never
land,
and
you
know
we'd
still
have
the
you
know:
hey
that's
been
five
months
or
whatever
the
the
thing
was.
A
You
know
it's
been
five
months
without
any
discussion
on
this
and
it's
over
a
year,
so
we're
going
to
close
it
if
there
isn't
any
discussion
in
the
next
month,
so
somebody
could
easily
chime
in
and
say
no
no.
No.
I
still
want
to
keep
this
alive,
but
otherwise
then
have
it
closed
when
it
hits
that
six-month
range
put
it
on
to
get.
You
know
to
find
out
if
there's
any
tsc
members
who
are
like
no,
no,
no,
we
should
absolutely
not
do
that
or
you
know
get
some
feedback.
A
There
was
some
discussion
in
the
issue
itself.
I
think
a
few
people
were
at
least
one
person
was
kind
of
like
well,
it's
not
very
friendly,
but
I
think
there's
enough
sort
of
counter
or
there's
enough
people
also
saying
well.
Actually
this
might
be
a
little
bit
friendlier
that
you
know
I'd
be
reasonably
comfortable
moving
forward
with
this,
you
know,
given
the
feedback,
that's
in
the
issue
itself,
but
I
wanted
to
have
it
on
the
agenda
here
to
see
you
know
people
have
thoughts,
they
want
to
add
into
the
discussion.
B
A
concrete
piece
of
feedback
that
I
and
probably
others
have
received
from
people
who
have.
Basically,
you
know
if
it's
possible
to
quietly
table
flip
and
go
away
but
quietly
table
flipped
and
go
away,
has
been
that
from
non-collaborators,
but
from
contributors
has
been
that
it
is
incredibly
frustrating
to
open
a
pull
request
and
not
get
a
yes
and
not
get
to
know
and
get
endless
discussion
and
blah
blah
blah
blah,
and
so
so.
B
So
I
think
closing
it
is
actually
a
kinder
better
thing
to
do
than
to
just
leave
it
open
and
have
it
be
something
that
we
all
know
is
never
actually
going
to
land
so
yeah.
I
think
so
I
I
I
I
I'm
normally
sympathetic
to
the
idea
that
bots
doing
things
can
seem
can
seem
impersonal,
at
least
but
yeah.
This
is
one
of
several
situations
in
node,
where
I'm
in
favor
of
the
bot
acting.
A
I
guess
like
in
absence
of
anybody
like
here,
showing
you
know
having
any
concerns,
I'd
volunteer
to
try
and
figure
out.
What
we
can
do
is
the
next
step
to
turn
it
turn
this
on.
I'm
not
sure
if
you
know
what
I
proposed,
the
stale
bot
will
just
do,
but
I
you
know,
as
long
as
people
are
like
yeah,
that
seems
reasonable
I'll
I'll.
Take
it
on
to
go.
Take
a
look,
see
how
we
figure
it
out.
B
A
A
Okay,
thanks
just
quickly
note
here,
discuss.
A
Okay,
the
next
one,
then,
is
number
four.
Two,
six
seven
five
butyl
add
parsergs
module
this
one.
I
know
I
don't
know
if
this
is
the
one
for
the
vote
or
not,
but
I
know
we
have
a
vote
and
I
guess
I
was
hoping
we
can
close
out
on
this
one.
A
C
Yeah,
so
it's
been
13
days
as
of
now
and
there
are
16
people
that
have
voted
so
yeah
four
that
have
not
yeah,
I'm
fine
with
closing
devotees.
If
no
one
has
the
objection.
B
C
The
threshold
would
be
if
there's
a
winner
like
I
mean
the
only
way
that
that
there's
no
result
if
eight
people,
but
one
thing
and
eight
people,
but
for
another
right.
B
Depends
on
the
number
of
abstentions?
Nothing!
It's
it's
all
right!
I
think
I'm
just
gonna,
I'm
gonna!
Actually,
I'm
just
I
rescind
my
question
just
I
forgot
that
we're
doing
condorcet,
and
that
makes
everything
quick
that
makes
questions
like
that
less
straightforward
than
they
than
they
are
than
they
have
been
in
the
past.
So
I'll
just
back
off.
A
A
A
All
right
anyway,
let's
move
on
anyways
yeah,
but
yes,
if
it
please
anyway,
so
we'll
go
on
to
the
next
one.
Global
fetch
break
source
map.
So
this
is
number
42638.
A
This
isn't
one
of
the
best
times,
but
I
think
the
issue
here,
let's
see,
is
there
anything
that
says
I
guess
the
the
fundamental
thing
is
that
making
it
global
collided
with,
I
think
polyfill
like
existing
modules
that
would
have
then
or
polyfills
that
would
have
added
it
and
because
it's
not
the
same
as
the
other
ones,
the
only
real
way
to
unbreak.
That
would
be
to
not
have
it
be
global,
so
I
think
that's
kind
of
why
it
was
on
the
agenda
was
for
us
to
discuss
that
aspect.
B
A
I
I'd
have
one
question
to
ask
and
then
we
can
move
on
if
nobody
has
strong
ideas
is
I
think
this
might
be
a
like,
not
not
only
a
fetch
question
but
sort
of
a
global
if
we,
if
we're,
if
we're
in,
if
we're
putting
apis
that
are
web
apis
and
that
are
global
in
the
browser,
should
they
be
automatically
global
in
the
in
node
or
not?
D
We
did
have
agreements
about
that
before.
I
believe
because,
like
as
at
least
as
far
as
I
remember,
we
have
like
always
when
there
was
a
new
api
added
to
node.
That
was
also
in
the
browser
as
global.
It
would
be
made
global
in
node
as
well.
A
Okay,
interesting
and
so
okay,
maybe
we'll
wait
to
let
mateo
lead
the
specific
discussion
here,
although
I
I
think
that's
really,
the
fundamental
question
is
like
we
broke
something
by
making
it
global.
What
do
we
do
so.
B
A
Yeah-
and
I
think
I
think
if
we
can
either
reaffirm
that
global
question
of
like
yeah
like
the
next
time,
the
exact
same
thing
could
happen
and
if
we
can
think
about
it
in
the
context
of
that
like
yes,
we
should
make
it
global
and
therefore
things
will
break
and
we
understand
that
that's
the
way
it
is
or
or
not
so
that
we
don't,
you
know,
have
to
discuss
the
same
kind
of
thing.
Every
time
think
about
it
in
that
context,
would
be
great.
A
Okay,
the
next
one
is
rename
default
branch
from
master
domain.
This
is
number
33
864
richard.
Do
you
want
to
update
us
on
that?
One.
E
Yeah
we've
just
in
the
last
20
minutes,
half
hour
renamed
the
branch
of
the
of
the
build
repo.
It
has
broken
the
windows
build
and
I
think
I've
just
fixed
it,
but
yeah
just
be
aware.
If
anything
looks
weird
in
the
ci
reported
either
on
the
slack
channel
or
open
an
issue,
we
think
we
thought
it
should
be
safe
to
do.
But
obviously
we've
missed
the
windows
thing,
but
the
branch
has
been
renamed
now.
So
it's
done
we'll
try
and
fix
up
anything
else
that
crops
up
if
it
does.
E
But
I
was.
E
Yeah
there
were
some
variables
embedded
in
the
job,
so
they
didn't
show
up.
When
we
searched
the
conference.
Repo
yep
sell
them.
I
think
I've
called
once
windows.
Hopefully
that
should
be
okay,
but
yeah
so
just
see.
Okay,.
A
You
know,
as
we
did,
that
we
had
a
discussion
and
we
think
can
the
same
in
the
same
sense
as
we
thought
for
the
build
repo
that
the
get
redirects
the
github,
redirects
and
sort
of
the
behavior
would
mean
that
actually
we're
okay,
in
renaming
the
main,
the
the
node
repo
as
well,
that
one
will
have
a
much
broader
impact
in
terms
of
all
the
collaborators
may
have,
you
know
will
have
to
do
some
work
in
terms
of
their
next
potential
push
or
landing
prs.
A
We
thought
it
would
be
a
good
place
here
in
the
tse
meeting
to
see
if
anybody
else
can
think
of
things
that
they
think
are
they're
worried
about
or
which
might
be
issues,
and
we
could
talk
about
that
and
then
also
talk
about.
What's
what
kind
of
messaging
should
we
do
before
we
do
that?
How
do
we
schedule
doing
it.
E
So
I
I
think
from
memory
the
main
concern
before
was
about
accidentally
pushing
to
a
branch
called
master
after
the
rename
happened.
There
are
now
protection
rules
in
github
for
preventing
accidental
pushes
to
named
branches
and
from
following
the
last
year,
sequel
nikita,
I
think,
came
up
with
a
workaround
to
stop
administrators
from
also
accidentally
pushing.
If
you
require
branches
to
to
have
signed
commits.
Most
of
our
repositories
have
a
mixture
of
signed
and
non-signed
commits,
which
would
seem
to
prevent
accidentally
pushing
to
those
branches.
E
So
I
think
we've
got
protection
rules
to
stop
people
accidentally
pushing
to
a
master
branch,
so
the
the
the
thing
that
would
break
would
be.
People
would
need
to
update
their
local
references
so
that,
instead
of
an
upstream
pointing
to
master,
it
would
have
to
point
point
to
the
renamed
branch,
which
is
going
to
be
main.
E
A
It
was
kind
of
an
edge
case,
and
it
may
be
that
github
fixed
some
things
after
after
we
thought
they
were
reported,
but
it
was
such
a
long
time
ago
that
I
don't
I
don't
remember
now
and
it
was
we've
remained
we've
renamed
we're
down
to
two.
We
just
did
build
so
we're
down
to
maybe
two
or
three
repos
and
the
rest
of
them
were
all
pretty
much
fought.
A
A
I
think
I'll
take
silence,
meaning.
No,
I
guess
then
the
next
specific
question
is
like:
what
do
we
think
is
enough?
Messaging
to
collaborators
is
like
we
can
open
an
issue
with
an
app
mention,
or
we
cannot
mention
the
issue.
We've
got
open.
What
do
we
think
we
need
to
do
in
terms
of
telling
people
it's
going
to
happen.
B
I
mean
at
mentioning
doing
both
of
those
things
you
know,
though,
and
and
other
than
that
I
don't
know
that
you
know-
maybe
maybe
something
in
the
open-
the
relevant,
open,
js
slack
channel.
Maybe
there
might
be
two
of
them
actually
and
yeah
I
mean
we
don't
want
to.
We
don't
want
to
email
collaborators
directly
and
we-
and
I
don't
know
that,
like
you
know,
tweeting
something
out
is
a
great
way
to
communicate
with
collaborators
or
anything.
B
I
don't
know
you
know
I
mean
the
other
thing
is
that,
like
you
know,
the
number
of
collaborators
that
this
is
actually
going
to
affect
is
just
the
most
of
the
people
who
actually
land
stuff.
You
know
locally.
Oh,
I
guess
we
probably
want
to
remember
that
no
triagers
can't
can't
push
so
yeah
yeah.
I
mean
the
number
of
collaborators
who
actually
be
affected
by
this
is
is
a
very
small
subset
of
the
full
collaborators
and
they're
very
active
and
they'll
see
these
things,
so
I
think
doing
those.
E
But
again
it's
going
to
be
a
small
proportion
of
collaborators
that
would
actually
need
to
do
that.
It
probably
comes
back
down
to
your
earlier
comment
about.
Pr's
have
been
open
for
ages.
E
I
think
this
comes
down
to
you
know
if
we
schedule
this
we're,
probably
as
ready
as
we
are
now,
then
you
know
right
now
in
another
month,
what's
going
to
change,
if
we're
not
actually,
if
we're
not
actively
doing
things,
I
don't
think
the
situation
will
be
any
different
next
month
or
two
months.
So
so
the
main
thing
is
to
you
know,
give
people
a
chance
to
say
well,
wait
a
minute
what
about
this
just
in
case
there
is
something
we've
forgotten,
but
then
other
than
that
pull
the
trigger.
E
I
guess
and
make
the
switch
and
deal
with
the
fallout.
B
E
A
I
think
you
know
from
what
I
hear
is
I
don't
hear
any
major
concerns.
I
hear
the
sort
of
what
I'm
you
know
what
you're
exposing
mentioning
there
like
we're,
probably
in
as
good
a
position
as
we're
gonna,
be
as
long
as
we
pick
a
date
which
is
like
we
picked
the
the
after
the
last
release
to
do
the
the
build
one
just
in
case.
A
Maybe
we
do
the
same
thing,
but
it
sounds
like
I
don't
hear
any
concerns
from
csc
members
on
proceeding,
and
you
know
you
know
richard
myself
and
anybody
else,
who's
kind
of
interested
in
doing
the
rename
and
being
you
know
watching
for
things
we
can
just
pick
a
date
and
move
forward.
Does
that
sound
right
to
everybody?
A
E
E
F
E
When
you,
when
you
rename
a
branch,
it
will
redirect
references
so,
for
example,
we've
renamed
build
now,
if
you
go
to
like
the
raw
urls
for
pulling
things
via
via
a
type
of
the
github
api
or
directly
from
the
web.
If
you
go
to
like
slash
master
as
the
branch
name,
github
will
redirect
you
to
main,
because
the
branch
has
been
renamed.
The
issue
before
was,
if
you
didn't,
have
branch
protection
in
place.
E
E
So
what
isn't
redirected
is
if
you
have
a
local
references
in
your
kit
to
check
out
so
if
you've
got
a
branch
locally
and
that's
set
an
upstream
to
like
or
upstream
master
origin
master,
whatever
you've
named
your
remote,
pointing
to
the
upstream
main
repository
that
you
would
have
to
manually,
update
and
yeah,
we
would
need
to
put
those
instructions.
Github
tells
you,
when
you
do
the
rename
but
we'll
copy
those
instructions
into
the
messaging
out
to
collaborators.
E
So
that's
the
only
thing
get
help
can't
update
your
own
local
references
and,
probably
probably
shouldn't
be
I
mean
you
should
be
in
control
of
your
own
references
given
that
gets
decentralized,
but
if
you're
going
via
the
web.
So
if
you
are,
you
know
trying
to
access
urls
to
github,
then
github
will
redirect.
A
B
Unless
it's
likely
to
change
our
decision,
should
we
right
now,
nuts
and
bolts
on
on
that
right
now,
because
I
I
I
do
want
to
make
sure
we
have
plenty
of
time
for
the
end
of
life
date
for
no
js
16
discussion,
yep.
A
A
I
see
I
see
some
nodding,
so
you
know
what
I've
noted
is.
You
know
no
concerns
from
tsp
members
on
proceeding.
We'll
pick
a
date
we'll
do
that
the
messaging,
which
is
basically
going
to
be
an
app
mention
and
some
slack
message,
attack
channel
posts
and
then
it'll
happen.
I
don't
want
to
split
hairs,
but
I
wouldn't.
B
A
B
A
Sure,
okay
got
it.
Okay,
we'll
move
on.
I
I
think
what
I'd
suggest
is
that
we,
I
guess
we
have
a
fair
amount
of
time
but
from
the
the
2022
tsc
chair
election.
That's
actually
quite
quick.
There
were
only
two
candidates
myself
for
chair
and
matteo
for
vice
chair.
A
You
know
unless
there's
objections
we
can
just
affirm
the
people.
I've
said
we,
you
know,
get
people
to
friday
to
do
that.
So
you
know
just
making
this
visible
here
and
otherwise.
We'll
declare
that
quote
by
the
end
of
the
week.
A
To
be
a
little
drama
yep
there
we
go
uh-huh,
okay,
so
done
that
we'll
move
on
to
the
next
one,
which
could
take
more
time
so
the
end
of
life
dates
for
node
16
and
opens
cell
1.1.1,
I'm
richard.
I
know
you've
been
sort
of
looking
at
this,
so
maybe
you
can
give
us
an
update.
E
Whether
we
could
take
future
pac
updates
of
openness
itself
from
from
red
hat
or
its
family
of
linux
distributions,
so,
for
example,
red
hat
eight
has
open
ssl
one
one
one
in
it,
and
that
will
be
supported
by
red
hat
in
their
distributions
until
the
end
of
life
of
red
hat
eight,
which
is
beyond
the
end
of
life
of
upstream
open
111
and
beyond
the
end
of
life
of
upstream
node
16..
E
I've
been
doing
a
sort
of
technical
evaluation
to
see
whether
we
could
even
just
technically
do
that
switch,
and
I've
run
into
a
few
issues
with
that.
So
it's
looking
doubtful
that
this
will
be
a
workable
solution
and
there
are
other
questions
over.
For
example,
even
though
it's
supported
in
red
hat,
it
would
only
be
tested
against
their
linux
distributions.
E
So
you
know
windows
mac,
it's
probably
a
low
chance
of
things
breaking
because
by
then
when
openness
still
is
openness,
so
one
one
stops
being
supported,
it's
very
likely
to
get
drastic
structural
changes,
but
yeah.
I
I
I
haven't
seen
anything
in
my
investigation
so
far
to
change
my
mind
from
the
initial
recommendation.
It
was
just.
I
was
asked
politely
to
to
exhaust
other
possibilities,
so
yeah
is
that
fair.
A
Michael
yeah,
I
think
I
think
basically,
when
we
started
it
was
like
hey,
maybe
there's
something
exactly
what
we
need
over
here
and
so
been
richard's,
been
looking
to
see
how
close
to
what
we
needed
is
or
isn't,
and
it
sounds
like
it's
less
close
than
we
thought,
which
means
it's
less
likely,
but
I
think
still
worth
you
know,
closing
out.
A
B
Since
there
is
consensus
on
ending
support
early,
I
don't
see
anybody
saying
not
to
and
a
lot
of
people
saying
we
should
including
me
and
richard.
I
wonder
if
we
should,
we
should
actually
make
that
decision
to
do
that
now
and
if
richard,
if
richard's
investigation
into
using
red
hat
open,
ssl
yada
yada
to
extend
support
actually
ends
up
panning
out,
we
can
always
revise
that.
We
can
always.
You
know,
rethink
that
that
decision
and
have
a
discussion.
B
But
since
that
seems
unlikely
I
I
wonder
if
we
want
to
make
the
decision
now,
unless
richard
feels
confident
that
he
only
needs
like
another
like
week
or
something
to
just
put
the
final
nail
in
the
coffin
so
to
speak
because
yeah
I
mean
like,
I
feel
like.
B
E
B
So,
okay,
so
in
so
so,
basically
in
a
nutshell,
then
richard's
gonna
look
at
stuff
a
few
more
days
and
barring
something
very
finding
something
very
unexpected
and
very
positive
about
the
possibility
of
going
that
route.
We're
just
going
to
decide
to
shorten
support
by
seven
months
next
week.
Is
that
like
roughly,
where
we're
at.
B
A
Okay
right
anybody
else,
no
other
comments,
thoughts.
A
We
can
move
on
to
the
strategic
initiatives,
then
let
me
just
get
there.
A
B
Exactly
one
of
the
things
I
thought
would
be
good
to
discuss
so,
given
that
we
probably
want
to
want
to
return
to
the
practice
of
soliciting
strategic
planning
updates
in
the
actual
issue
and
at
mentioning
people
who
are
the
who
are
the
champions
to
provide
those
updates
in
the
in
the
issue.
And
then,
if,
if
you
know,
if
we,
if
we
need
an
update
at
a
meeting
for
a
strategic
initiative
that
isn't
a
tsc
members
initiative,
we
can
invite
the
person
as
a
guest.
A
Yeah,
I
offered
you
know
I
asked
chenzong
to
like
kf.
You
can
give
us
comment
like
people
have
been
doing
on
the
issue
and
also
that,
like
opened
the
said
hey,
if
you
know,
if
you
want
to
give
a
live
update,
just
let
me
know
and
we'll
get
you
on
the
agenda
this.
This
is
kind
of
like
a
little
new
for
us,
but
I
think
is
the
right
thing
to
do.
A
Is
that
we
don't
need
tse
members
to
be
the
champions
we
want
to
enable
other
people,
so
we
can
see
how
that
goes
and
like
if
that
turns
out
to
be
a
barrier,
maybe
we'll
think
of
something
else
and
we'll
try
and,
like
you
know,
look
at
those
updates.
Still
in
this
section,
I
think
it's
good
for
us
to
look
at
them,
because
one
of
the
goals
is
to
make
sure
that
we're
aware
of
what's
going
on
and
so
forth
there,
and
that
one
is
on
the
shadow
realm.
It
looks
interesting.
A
It
may
be
sort
of
a
longer
term
challenging
thing,
but
I
think
it's
interesting
it'd
be
good
to
have
some
visibility
on
the
tse
on
work
going
on
there
looking
at
the
ones
that
are
in
the
list,
so
poor
promise
apis
antoine
anything.
To
mention
on
that.
One.
A
On
the
next
10,
I
don't
have
an
update
other
than
you
know.
We
do
have
a
number
of
sessions
planned
for
the
openjs
collaborator
summit,
both
some
ones
which
are
specific
to
the
next
n
or
related.
I
think
there's
one
in
dc,
so
I
think
we'll
have
some
good
sessions
there
and
I
think
that
covers
the
current
strategic
initiatives.