►
From YouTube: 2020-10-01-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
Welcome
to
the
node
technical
steering
committee
meeting
for
october
1st
2020.
we'll
follow
the
standard
agenda
which
was
as
identified
in
issue
number
933
within
the
tse
repo.
Before
we
get
to
the
issues
tagged
for
the
agenda,
does
anybody
have
any
announcements
that
they'd
like
to.
A
A
Okay,
so
no
announcements
this
week.
So
let's
move
on
to
the
issues
that
were
tagged
for
the
agenda.
The
first
one
is
make
recursive
rmd
or
more
strict.
This
is
35
250.
and
we
have
benjamin
here
today
as
a
guest
to
help
us
talk
through
and
give
us
some
context
on
that.
One.
B
Yeah,
let
me
give
you
you
want
me
to
jump
right
in
yep,
so
we
wanted
to
add
recursive
remove
functionality
about
a
year
ago.
We
added
it.
So
it's
been
kind
of
an
experimental
status
for
quite
some
time.
There
was
a
lot
of
discussion
when
we
originally
added
it.
It
was
you
know,
there's
there
was
a
couple
attempted
and
then
removed
to
attempts
at
it
and
long
story
short.
B
We
landed
on
it
being
a
feature
on
render
doing
a
little
bit
of
a
literature
review
of
other
languages.
I
don't
think
this
is
a
huge
deal.
Lots
of
languages
have
recursive
remove
like,
like,
I
kind
of
summarize
it
in
that
issue,
like
dino.
Has
it
net?
Has
it
there's
a
couple
other?
B
What's
a
little
weird
about
our
implementation
and
what
a
few
folks
have
come
in
and
chimed
in
about
is
we
are
really
loose
about
not
throwing
on
errors
compared
to
what
I
saw
in
a
lot
of
other
languages
like
like.
We
allow
you
to
give
it
a
path
that
doesn't
exist
and
it
just
kind
of
eats
that
error.
We
allow
you
to
give
it
a
file
instead
of
directory
paths,
which
is
kind
of
a
little
confusing,
because
it's
on
the
the
remove
directory
method.
B
So
a
couple
of
folks
from
the
community
came
in
and
like
a
couple
months
ago
and
and
it
was-
and
they
kind
of
made
the
case
like
listen.
This
is
really
loose.
We
can't
catch
errors,
it's
it's
difficult
and,
and
we
kind
of
kind
of
had
a
contentious
discussion
around
it.
B
I
was
of
the
of
the
of
the
opinion
that
we've
had
it
on
rimder
for
a
year.
It
has
a
lot
of
adoption.
If
you,
google,
github,
like
we
ourselves,
use
it
quite
a
bit
I'd
like
to
get
it
out
of
experimental,
but
I
did
start
to
come
around
to
this
argument
that
we're
really
loose
on
suppressing
errors,
which
is
a
little
weird
so
so
I
was
like
well,
okay,
like
what,
if
we
have
a
flag
that
lets
you
be
more
loosey-goosey,
but
we,
but
we
kind
of
move
towards
a
stricter
implementation.
B
That
is
a
little
more
in
line
with
what
other
frameworks
are
doing
so
like
throw
and
throw
if
you
give
it
a
file
instead
of
a
path
throw
if
you
give
it
a
path
that
doesn't
exist,
that's
in
line
with
net,
but
another
person
on
the
node
project
said
they'd
be
a
pretty
hard
minus
one
g1,
because
it
would
just
be
inconvenient
to
have
to
be
checking
paths
before
you
do
the
do
the
delete.
B
So
I
think
we've
kind
of
we've
hit
this
impasse
right.
Oh
yeah
go
ahead!
I
have
one
quick
question
on
that.
One,
like.
A
C
C
A
B
I
think
it's
more
likely
that
I
think
people
are
using
the
recursive
functionality
a
lot
for
it
would
be
for
like
cleanup
steps
like
you,
have
a
disc,
folder,
you're,
always
cleaning
up,
so
it
would,
it
would
be
like
you
haven't,
run
compiled,
but
you
have
a
cleanup
step
that
always
deletes
that
disk.
A
B
Yeah
exactly
right,
okay,
so
so
so
I
think
the
two,
the
two
kind
of
options
that
are
there's
three
options
out
there,
really,
the
third
one.
I
don't
know
if
it's
actually
a
viable
option.
The
first
option
would
be
we
kind
of
go
stricter.
We
match.net's
behavior,
so
it's
kind
of
it
is
breaking
for
the
community.
It's
it
will
catch
some
people,
but
but
it's
a
little
more
in
line.
B
You
don't
throw
on
those
two
error
cases,
but
there
is
a
way
to
make
it
stricter
for
for
people,
so
you
can
pass
like
a
strict
flag
or
something,
and
suddenly
you
get
the
behavior
that's
closer
to
net
or
dino
or
or
python.
B
The
third
case
that
people
are
arguing
adamantly
for
was
that
we
only
have
the
strict
functionality
and
we
revisit
that
decision
from
a
year
ago
and
pull
it
out
into
its
own
method,
where
it's.
We
have
like
a
rmrf
method,
which
is
what
ruby
has
so
ruby
has
no
recursive
like
rmdir,
but
they
have
a
rmrf
method
that
behaves
like
ours
does
today.
B
So
there's
we're
just
having
trouble
reaching.
I
think,
like
my
what
I
feel
strongest
about
is,
I
think
it's
really
should
get
this
thing
away
from
being
experimental,
like
people
are
relying
on
it
like
it's
a
really
useful
feature.
It's
not
it's
not
reinventing
the
wheel,
a
lot
of
other
languages
have
it,
but
like
there's
a
lot
of
contention
around
like
do
we
start
do
we
go
stricter
and
you
can
provide
a
config
to
go
to
looser.
Do
we
stick
to
our
guns
with
the
really
loose
approach?
A
D
B
E
F
E
F
Right
but
given
given
its
wide
adoption,
you
know
we're
going
to
be
causing
a
lot
of
breakage
while
we
hide
behind
the
veil
of
it
being
experimental
right
which,
which
is
which
is
all
right,
because
that's
what
experimental
means,
but
I
mean
do
we
actually
want
that
kind
of
breakage
right,
but
I
I
kind
of
agree
with
you
I
was
also.
I
was
also
thinking
from
what
from
what
ben
was
saying,
that
it's
kind
of
a
misnomer
to
call
it
rmdir,
because
rmdir
is
the
sensitive
variety
rm
minus
rf
is
like
the
sledgehammer.
E
Yeah
I
mean
the
point:
is
today
if
we
agree
or
if
you
look
at
the
wide
adoption
and
try
to
set
it
as
a
standard
tomorrow,
another
set
of
people
can
come
and
say:
hey
look.
This
is
not
at
all
conformance
to
the
the
standard
oils
practices,
so
there
will
always
be
two
types
of
arguments
and
that's
the
that
that
would
be
the
very
root
of
our
experimental
versus
table.
Graduation
model
where
we
came
up.
B
I
would
like
I'm
not
in
disagreement
that
I
think
that
I
think
it
would
be
less
disruptive
to
people
if
we
went
the
dot-net
kind
of
recursive
approach,
which
is
like
we
throw
on
we
we
look.
I
I
think
we
went
all
the
way
to
python's
api,
which,
which
is
exactly
the
same
as
render
where
so
it
has
to
be
an
empty
folder
already.
B
But
I
think
that's
not
that
useful
of
a
feature
and
it's
I
think
it
would
like
at
that
point
like
you
might
as
well.
Just
like
it's
just.
I
don't
think
that
useful
for
the
existing
users
of
this
who
are
using
it
to
clean
up
like
a
disc
folder,
but
I
think
if
we
were
going
to
go
really
so
the
strictness
I
would
advocate
would
be
we
throw
on
file
paths
we
throw
on
missing
paths
so
that
people
can
start
to
do
some
error
handling.
A
B
Yeah,
I
agree
and-
and
I
like
I'm
kind
of
I
question
like
how
much
I
don't
know-
maybe
people
are
building
different
things
than
me
but,
like
I
feel
like
having
the
recursive
method,
where
I
have
to
already
have
emptied
the
folder
and
and
like
have
to
admit
all
these
constraints.
Already,
it's
not
that
useful
right,
like
from
a
from.
F
Honestly,
honestly
to
me,
since
we've
already
called
it
room
dear
to
me,
what
would
make
sense
would
be
like
room
deer,
and
then
you
have
flags
right,
you,
you
have
recurse,
and
then
you
have
force
just
like
with
rm
right,
and
so
we
we
will
kind
of
have
rolled
rm
and
room
deer
into
one.
F
A
F
D
So
so,
overall,
we
all
seem
to
agree
that
it
is
useful
to
have
those
modes,
one
that
is
going
to
remove
potential
files
in
the
folders
and
and
that's
just
going
to
be
like
rm,
rf
and.
C
D
That's
what
I
would
do
at
the
moment,
and
even
though
it
is
experimental,
I
do
see
the
point
into
changing
the
default
to
be
the
more
strict
one,
because
that's
more
fitting
to
the
name
and
to
add
a
new
one,
but
to
keep
in
the
behavior
at
least
for
a
while
and
to
add
a
duplication
warning
in
case.
There
is
something
detected
that
would
break
the
user.
That
way
they
have
intermediate
time
but
they're
able
to
switch
into
in
the
new
api,
and
then
we
are
good
to
go.
G
C
G
Let's,
essentially
it's
if
people
are
using
these
in
the
wild,
let's
just
deprecate
it
deprecate.
What
is
in
there
right
now
and
do
a
full
duplication
cycle
and
then
in
15
leave
it
as
it
is
in
14.
G
C
B
B
B
A
A
B
B
No,
that
seems
like
I'm
open
to
that
like,
like,
I
think
like
so
so
we
like
mateo,
said
we
it's
not
experimental,
but
we're
telling
people
it's
deprecated
and
we
have
this.
All
you
have
to
do
is
rename
your
rib
rimder
recursive
over
to
our
mrf
and
it's
the
exact
same
behavior
just
migrate,
your
app
to
this
right
and
we
stop
fiddling
with
flags
which
I
think
does
start
to
get
a
little
like
choose
your
own
adventure,
which
is
kind
of
not
great.
F
F
A
B
B
A
B
G
G
A
F
F
Sorry
go
ahead,
okay,
so
if,
if,
if
we
do
this
alias
right,
then
then
the
warning
that
we
would
throw
about
if
we
were
to
do
the
the
code
warning
rather
than
the
dock
warning,
would
we
throw
or
would
we
produce
the
warning
only
if
rmdir
would
be
used
in
such
a
way
that
would
be
normally
covered
by
the
new
function?
Rmrf,
because
I
mean,
if
you
do,
if
you
you
remove
non-recursively
an
empty
directory,
there
should
be
no
warning
right,
because
that's
what
we
intend
rmdir
to
be
eventually.
B
G
G
Okay,
so
the
key,
so
the
important
point
in
this
decision
is
how
much
it's
used
in
the
wild.
So
what
key
modules
are
using
this
api
out
there
if
it's
used
by
rimraf
or
something
like
that
or
whatever,
then,
which
would,
if
we,
if
we
removed
it
today,
how
much
what
would
break
in
the
ecosystem?
This
is
the
question.
B
There's
definitely
like
I've
done
some
research
like
if
you
even
just
look
on
github
for
render
node
recursive
true,
there's
hundreds
hundreds
or
thousands
of
projects,
but
even
like
I
was
talking
to
my
friends
who
are
working
on
redwood.js,
which
is
a
framework
for
and
they
use
it
like.
Everyone
uses
it
because
they
they
miss
the
fact
that
it
was
experimental
like
and-
and
I
think
that's
a
speaks
to
bad
like
that
speaks
to.
B
We
should
have
had
an
experimental
warning
in
the
console
from
day
one
and
we
didn't,
because
we
we,
we
went
with
the
loose
experimental
in
the
docks
and
it
kind
of
I
think
that
was
a
process
issue
that
should
be
could
be
revisited
like
it
should
be
thought
about
in
the
future.
If
we
had
more
popular
features
like
this,
I
think
it's,
I
think
it's
out
of
pandora's
box
for
sure.
D
So
I
try
to
summarize
it
again
and
text
and
I
see
like
four
main
steps:
let's
mark
the
current
api
as
stable,
since
it's
used
a
lot.
We
all
agree
upon
that.
Second,
let's
and
rename
the
current
api
in
a
way
that
we
add
a
new
one.
For
example
rm
you
could
use
a
different
name,
maybe
a
different
flag.
D
I
don't
care
while
keeping
the
current
api
still
working
as
an
alias
and
and
then
we
duplicate
the
alias
and
as
a
fourth
step,
we
add
a
new
functionality
and
wherever
I
don't
know
that,
has
this
stricter
version
that
people
would
expect
with
the
current
api.
B
D
B
F
A
Yeah,
I
I
do
think
we're
gonna
find
like
we've.
We've
had
some
things,
we've
tried
to
deprecate
that
have
dragged
out
for
a
long
time,
but
so
I
just
wonder
if
you
know
how
how
if
it
will
ever
actually
be
deprecated,
but
I
guess
this
one
is
fairly
easy.
It's
fairly
easy
to
move
right,
so
maybe
it'll
have
an
easier
chance.
So
I'm
just
taking
this
so
that
the
steps
are
duplicate.
Current
recursive
functionality
add
copy
as
rmrf.
B
B
If
not,
okay,
let's
move
to
the
next.
A
A
A
Okay,
let's
then
move
on
to
the
next
one,
which
is
number
35092
puny
code,
runtime,
deprecation.
H
A
I
I
Yeah,
it's
been,
you
know,
doc,
deprecated,
I'm
sorry
yeah.
Do
I
think
this
comes
down
to
do.
We
want
to
actually.
H
H
They
don't
list
in
in
dependencies,
and
it
should
probably
go
through
pending
duplication
process
first,
so
that
it
would
be
easier
to
trace
if
one
of
some
dependencies
uses
that
or
not,
and
moreover,
we
can
notify
packages
that
shine
brought
about
the
hr
users
which
run
in
the
application
flag
can
modify.
Those
also.
H
A
C
I
But
anyway,
so
I
see
tons
of
of
deprecations
when
using
npm
when
using
all
sorts
of
things,
and
so
I
I
actually
think
we
want
to
be
judicious
with
that,
because
you
know
we
we
want.
We
want
people
to
see
warnings
when
they
turn
on
pending
deprecations,
but
we
don't
want
people
to
become
numb
to
them
and
I
am
numb
to
them.
I
I
I
see
them
all
the
time
now
and
I
you
know
I
I
just
yesterday
got
confused
between
process
binding
and
process
umass
deprecations,
because
I'm
seeing
30
deprecations
every
time
I
run
npm,
you
know,
and
so
I
yeah
I
but
that's
a
larger
conversation.
Actually,
let's
focus
is
back
on
puny
code
sure,
but
I
I
see
your
point
just
wanted
to
offer
that
the
my
experience
running
pending
deprecations
is
that
I
now
just
ignore
all
the
all
the
deprecation
warnings
and
maybe
I'm
doing
it
wrong.
I
A
A
I
Maybe
that
and
also
treat
warnings
as
errors
is
a
pretty
potent
combination
right,
but
back
to
puny
code.
Do
we
do?
Did
we
deprecate
it
because
it's
not
being
maintained
upstream
anymore
or
we
we
plan
on
stopping
using
it
or
what
was
the
reason
for
it
or
just
we
should
have
never
exposed
it
in
the
first.
I
Place,
I
actually
wonder
if
we
want
to
punt
on
this
for
now
and
get
to
miles's
npm
7
thing,
because
that's
probably
that's
that
that's
that's
urgent,
whereas
this,
if
this
waits
another
week
or
something
that's
fine,.
H
H
Be
moved
back
to
github
or
do
you
think
h.
I
Okay,
I'll
take
the
tag
off
and
I'll
also
mention
that
I
I
like
chalker's
suggestion
and
maybe
we'll
see
if
that
moves
it
forward
a
bit.
A
J
J
Excuse
me,
our
hope
and
intention
is
to
have
this
ship
in
in
node.js
15..
We
had
a
little
bit
of
a
policy
discussion
in
in
the
issue
tracker,
which
was
great.
J
We
got
to
the
bottom
of
what
our
official
policy
is
right
now,
which
is
that
december
majors
that
want
to
land
after
the
cutoff
of
one
month
before
a
sember
major
release
just
requires
there's
no
objections
from
the
tsc,
so
I
guess
you
could
think
of
this
as
kind
of
like
a
impromptu,
a
heads-up
about
what's
going
on
and
ability
to
answer
some
questions,
so
we
can
kind
of
just
get
ahead
of
it
recognize
that
we
do
not
have
the
whole
tsc
here,
but
we
do
have
quorum,
so
that
is
nice
and
just
to
like
clarify
one
more
time.
J
This
is
not,
I
guess,
seeking
approval
as
I
originally
framed
it.
It
is
more
just
like
you
know,
seeking
seeking
consensus
and
ensuring
that
there
would
be.
You
know
no
objections,
so
the
pr
that
we
have
open
right
now
does
require
you
know,
maybe
a
little
bit
of
tweaking.
I
can
see
that
the
the
linter
was
broken
I'll,
dig
that
up
and
we'll
fix
that
as
soon
as
possible.
Npm
7
does
have
some
breaking
changes
that
we've
shown
shared
with
you
in
the
past.
J
The
largest
of
these
breaking
changes,
at
least
the
intentional
ones,
is
the
changing
to
the
algorithm
for
pure
dependencies.
Pure
dependencies
are
now
being
like,
verified
and
enforced.
One
of
the
changes
that
we
did
make
based
on
feedback
is
that
the
majority
of
cases
where
peer
dependencies
fail.
J
The
result
of
this
is
that,
once
we
fix
one
more
bug
which
I'll
talk
about
in
a
second,
there
are
no
additional
failures.
In
sitkin
after
we
introduced
npm,
seven
all
of
the
modules
in
sitkium
that
passed
before
and
all
of
the
platforms
pass,
the
exact
same
way.
There
is
currently
one
bug
that
we've
found
that
is
specific
to
resource
constrained
hardware
so,
and
it
is
only
manifesting
in
osx
on
ci,
and
it
is
only
manifesting
and
it
manifests
more
when
we're
running
more
jobs
at
the
same
time.
J
So
there's
we
believe
it's
a
stream
based
race
condition.
We
are
looking
between
it
being
potentially
cpu
or
network
exhaustion,
but
we,
the
team,
is
actively
working
on
that
right
now.
But
the
the
plan
for
the
moment
is,
you
know
we
want
this
rc
we'd
love
to
see
it
land
on
master.
J
So
moving
out
of
release,
candidacy
and
we'd
like
to
see
that
7.0.0
release
go
out
with
with
the
note
15,
I'm.
I
J
Well,
so
so
kind
of
yes
I'll,
be
more
explicit
now,
so
the
npm
team
has
a
target
date
of
the
13th
of
october
to
cut
the
december
major
release
and
move
it
out
of
release
candidacy,
which
gives
a
full
week
prior
to
december.
Major
release
of
note
15
and
the
npm
team
would
like
to
see
this
ship
with
me
as
an
individual
as
both
a
release
team
member
as
well
as
a
tsc
member.
I
think
that
this
is
the
best
thing
for
us
to
do
as
a
project.
J
It
will
not
be
without
you
know
its
ecosystem
disruptions.
It
is,
you
know,
including
breaking
changes,
but
I
think
that
it's
important
that
we
get
this
into
people's
hands
as
soon
as
possible
that
we
get
the
feedback
based
on
it
as
soon
as
possible
and
that
we
quickly
iterate
and
fix
problems
that
we
run
into.
J
I
think
longer
term
there's
an
interest
in
seeing
if
this
could
get
backported
to
14,
but
I
think
that
that
would
be
you
know,
months
from
now,
after
it's
had
more
ecosystem
usage,
when
we
can
show
whether
or
not
like
categorically
that
there
would
be
no
big
changes
in
behavior,
we
do
have
ideas
about
how
to
land
this
in
a
way
that
would
not
change
the
peer
dependency
behavior,
but
we'd
also
want
to
ensure
a
similar
level
of
correctness
as
well
as
performance
and
for
the
npm
cli
team.
J
This
quarter,
like
that
is
one
of
their
major
focuses
that
their
engineering
effort
is
going
to
be
going
towards,
is
improving.
Documentation
is
improving
performances
and
improving
correctness,
and
you
know
making
sure
that
this
you
know
this
release
is
extremely
high.
Quality.
I
So
I
I
support
this
completely,
especially,
given
that
it's
an
it's
a
release.
That's
never
going
to
be
lts
15.,
with
the
sole
condition
that
you
know.
I
defer
to
release
working
group
on.
You
know,
like
obviously
the
release
working
group
has
final
say
on
whether
something
goes
in
the
release
or
not
so
whatever
they
say
goes,
but
I
support
this
completely.
I
think
it's
the
way
to.
I
A
J
Once
we
found
like
there
were
some
bugs
in
the
change
that
we
fixed,
but
once
we
caught
those
bugs,
there
were
only
two
modules
that
were
broken
by
this
and
the
additional
change
that
we
made.
That
kind
of
is
like
a
fallback
that
that
left
us
with
zero.
J
Also,
if
someone
runs
npm
install
and
the
pure
depth
change
does
cause
a
problem.
There
is
a
clear
warning
that
has
two
different
remediations,
including
running
npm,
with
force,
which
is
the
default.
We
do
a
subset
of
that
now
by
default,
which
is
the
fallback
option,
but
you
can
also
pass
dash
dash
legacy
peer
taps,
which
is
also
something
you
can
pass
as
a
command
line
argument
as
a
environment
variable
or
set
in
your
mpmrc,
and
that
will
use
the
legacy
algorithm.
J
So
I
would
say
like
similar
to
node
when
we
do
these
kinds
of
breaking
changes.
Yes,
it
may
break
things,
but
it's
completely
reversible,
so
people
can
work
in
their
environments
to
like,
if
that
specific
change
is
causing
a
problem
for
them.
There's
ways
to
avoid
the
breakage.
A
C
J
J
A
A
J
Lts
reasons,
and
and
regarding
like
long-term
plans
with
the
with
the
pure
depths,
I
think
the
intent
is
like
we're
giving
the
equivalent
of
like
a
runtime
warning
right
now
so
like
if
we
see
that
error
of
mismatched
pure
depths
into
your
tree,
we're
gonna
like
print
a
warning
right
now
and
we're
gonna
do
like
like
the
better
behavior
which
isn't
like
experience
breaking,
but
I
do
think
that
longer
term
the
team
is
interested
in.
You
know
changing
that
default.
J
That
would
have
to
come
in
another
semver
major
release
and
I
think
coming
like,
as
we
get
closer
to
16,
we
can
have
a
discussion
about
like
what
the
appropriate
defaults
are
there,
but
it
may
not
be
till
17
or
18
that
we
think
about
doing
that.
But
but
it's
like,
I
just
want
to
make
it
clear
that
there's
like
there
is
intent
in
deprecating
this.
But
I
think
this
is
similar
to
like
how
we
do
deprecations
in
node.
Let's
take
it
one
release
at
a
time.
J
A
Yeah
yeah,
based
on
that
it
sounds
like
you
know,
15
is
the
right
time
to
do
it
and
you've
taken
all
the
actions
to
make
it
easy
for
people
to
cope
if
they,
if
it
does
cause
them
problems,
while
we
then
figure
out
and
get
that
feedback
so
seems
reasonable
to
me
again,
like
like
rich
said.
As
long
as
the
release
team's
in
has
consensus
sounds
reasonable
to
me
personally,.
A
Any
other
we
still
do
have
a
few
things
on
the
agenda
that
we
can
try
to
get
to.
If
there's,
unless
there's
some
other
discussion,
we
want
on
this
one.
A
C
I
think
it
may
have
been
added
to
talk
about
the
umass
deprecation
revert.
A
C
So
yeah
I
opened
apr
to
revert
the
deprecation.
It's
got
approvals.
I
think,
there's
no
blocking
in
objections.
I
think
we're
probably
gonna
go
ahead
and
land
that.
A
Okay,
I
think
that
that
I'm
happy,
then
that
we
don't
have
any
don't
need
to
discuss
it
any
further.
Does
anybody
else
have
any
questions
comments
otherwise,
I'll
just
take
the
tsc
agenda
label
off
of.
A
A
Okay,
next
issue,
then,
is
33.
879
drop
minimum
waiting
time
as
a
hard
guideline.
We
did
discuss
this
last
time
and
I'm
just
opening
it
up.
I
think
we'd
gone
back
with
a
suggestion.
A
I
thought
we'd
had
a
concrete
suggestion
that
perhaps
mary
was
going
to
take
back
to
the
issue.
A
A
A
To
the
issue
yeah,
okay
and
close,
so
I
think
maybe
we
should
leave
on
just
as
a
reminder,
but
that's
that's
the
next
step,
so
I'm
going
to
just
copy
that
into
this
week
rename
default
branch
from
master
domain.
You
know
I
I
don't
know
miles.
You've
been
active
on
that
front
and
there's
sort
of
plugged
into
what's
going
on
on
the
github
front.
Anything
we
should
discuss
on
about
that
this
week.
J
Github
has
started
releasing
some
more
of
the
tools
that
make
it
easier
to
convert
directly
from
inside
of
the
repo
I've
been
off
the
last
week,
so
I
haven't
had
a
chance
to
kind
of
get
caught
up
on
where
it's
at.
I
feel
like
the
next
step
for
us
as
an
org
is
probably
converting
one
of
the
repos
that
has
a
little
bit
more
integration
and
eyes
on
it,
so
maybe
nodejs.org
or
nodejs.dev.
J
So
I
can
start
digging
into
that.
Next.
We
can
try
to
get
a
few
more
repos
kind
of
through
this
process.
A
A
A
Just
opening
that
up
so
reuben,
this
is
your
pr.
I
think.
Actually
it's
been
on
the
agenda
a
few
times
that
we've
skipped,
so
we
have
five
minutes
now.
I
don't
know
if
that's
enough.
D
So
matia
added
it
into
the
list,
because
it's
more
of
a
general
question
we
had
it
was
there.
There
is
an
implicit
breaking
change.
A
D
D
D
But
we
should
find
a
way
to
go
in
the
future
about
this
behavior.
A
I
think,
like
I
I
like,
if
we
don't
have
any
guidance
anywhere,
would
it
make
sense
to
write
some
guidance
that
says
that
picks?
One
of
these
cases,
like
you,
said,
there's
different
options.
It
picks
us
picks
one
of
the
cases
and
basically
we
pr
that
in
somewhere
and
once
we
have
agreement
on
that,
that
kind
of
informs
what
we
should
do
here
right
like.
A
Well,
somewhere
that
says,
like
hey,
you
know,
I
don't
know
if
we
have
anywhere,
I
don't
know
off
the
top,
my
head,
that
says
like
hey,
if
you're
building,
if
you're
creating
a
new
api.
These
are
the
things
that
you
know
that
the
project
has
agreed
constrain
our
apis.
We
have
something
along
those
lines
for
adding
an
api
apis.
It's
like
these
are
sort
of
as
the
team.
This
is
what
we
think
is
important
that
they
why
we
would
add
them.
You
know
characteristics
if
we
had
something
similar.
D
Right,
but
we
should
probably
also
have
something
like
that
outlined
in
our
general
documentation
for
the
users
so
that
they
would
know
if
it
is
a
supported.
Behavior
right
have
prototype
properties
on
input
objects
or
not.
A
A
A
H
A
Absence
yeah,
I
would
assume
it's
a
no
from
this
group,
so,
okay,
I
think
that
the
we're
basically
at
the
end
of
the
issues
and
we're
at
the
end
of
time,
we
don't
have
enough
time
to
go
through
strategic
initiatives,
this
time
so
we'll
skip.
That
is
there
anything
else
that
people
think
we
we
need
to
touch
on
before
we
close
out.