►
From YouTube: 2022-06-29-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
A
Okay
sounds
like
we
don't
have
any
announcements
in
terms
of
updates
from
the
cpc
and
board.
I
don't
have
any
updates
from
the
board
and
I
guess,
since
we
don't
have
rich
this
week,
I
think
on
the
cpc
front
was
a
working
session.
A
I
wasn't
able
to
make
that
so
I
don't
think
we
have
any
updates
this
week
on
this
on
either
of
those
fronts.
A
A
C
Yeah
yeah,
I
opened
that
because
I
think
there
are
advantages
of
doing
it
outside
of
core.
Specifically,
we
can
do
bug
fixes
and
things
like
that
and
get
them
out
to
users
much
earlier
than
is
the
case
today
and
given
how
we've
been
doing
indici
and
bringing
that
into
node
core
and
that's
proven
to
work
quite
well.
I
think
we
should
apply
this
same
workflow
for
streams
as
well.
B
Well,
it
was
it
I
would
not
like
up
until
a
few
months
ago,
a
few
weeks
ago,
I
would
not
like
it
was
so
old,
the
readable
stream
package.
That's
probably
was
not
worth
using,
so
I
was
not
even
recommending
it,
but
if
we
can
keep
that
up
today-
and
this
is
the
problem
that
the
thing
was
diverged
pretty.
E
The
one
question
I
and
I
think
I
raised
this
concern
in
the
thread-
is
about
the
the
rate
of
breaking
changes.
All
right.
You
know
my
my
one
fear
would
be
that
this
would
actually
accelerate
the
the
possibility
of
breaking
changes
in
that
api.
So
what
do
do
we
need
to
do?
Have
any
processes
in
place
to
make
sure
that
those
any
breaking
changes
that
do
happen?
There
are
visible
to
the
gsc
for
review.
E
Well,
yeah,
I
mean
within
vichy
at
least
we're
not
exposing
any
of
that
actual.
You
know
api.
If
breaking
change
is
happening
in
dc's
api,
then
it's
that's
one
thing:
it's
it's
just
it's
just
limited
to
fetch,
which
is
a
standard
api
and
we're
going
to
have
visibility
on
the
breaking
changes,
we're
not
necessarily
responsible
for
doing
those,
and
it's
unlikely
that's
going
to
happen.
E
C
C
Well,
there
are
multiple
motivations
like
it
makes
contributing
to
stream
easier.
It
also
allows
us
to
push
out
fixes
earlier.
C
So,
for
example,
I
don't
know
how
relevant
this
is
right
now,
but
but
historically,
we've
done
a
lot
of
fixes
for
streams,
including
some
very
major
ones,
that
users
haven't
been
able
to
take
advantage
of
until
we
just,
for
example,
do
a
semver
major
release
of
note
and
there's
no
actual
reason
why
users
couldn't
take
advantage
of
that.
A
F
So
one
question
I
have
is
how:
how
will
we
deal
with
at
the
moment
streams?
Is
it
does
behave
differently
between
the
different
versions
of
node
in
that
because,
like
you
said,
we've
not
taken
december
major
changes
into
obviously
because
december
major
into
the
earlier
release
lines-
and
you
know
we
we've
had
issues
where
things
have
been
backcourted
where
they
shouldn't
have
been
backboarded,
because
they
were
actually
dependent
on
other
changes.
Then
things
weren't
labeled.
F
F
Okay,
no
because
yeah
I
mean
the
reason
that
the
reason
we
don't
take
breaking
changes
into
the
you
know,
early
releases
of
node
is
because
by
definition
they're
breaking-
and
you
know
we
did
follow
sunburst.
So
I
I
guess
what
is
the
argument
that
it
would
free
people
from
being
tied
to
a
particular
version
of
strings
for
a
particular
version
of
node,
in
that
they
can
break
themselves
if
they,
if
their
team,
they
deem
that's
what
they
want
to
do
on
a
on
an
lts
line.
C
I
mean,
for
example,
there
was
a
comment
here
with
happy
that
the
happy
has
been
broken
with
the
stream
changes.
C
C
So
I
mean
the
the
thinking
here
is:
do
we
want
people
to
use
the
core
streams
or
the
package
streams?
The
upside
of
using
the
package
stream
is
that
people
can
choose
to
update
whenever
they
want,
and
then
they
don't
get
force.
The
you
know
force
broken
by
assembler
major
of
note.
F
C
Yeah
my
primary
issue
is:
if
we
want
people
to
break
themselves,
use
the
package,
then
you
know
avoiding
the
situation.
We
were
in
just
a
few
months
where,
where
the
package
is
you
know,
years
behind,
node
core
is
not
a
good
idea
and
I
think
an
easy
way
to
avoid
that
is
to
do
the
development
in
the
package.
G
F
G
C
F
I
guess
my
other
concern
is:
if
we
encourage
modules
out
there
to
switch
to
the
standalone,
readable
stream,
then
we
would
potentially
have
less
coverage
of
the
sort
of
inbuilt,
readable
stream,
and
I'm
I
kind
of
have
this
negative
feeling
that
the
coverage
we
have
it's
already
in
sitching
is
probably
not
extensive
enough
to
be
catching.
E
So
you
know,
you
know
colin
makes
the
point
during
the
chat.
You
know
we
just
slow
down
the
breaking
changes
to
streams
yeah.
I
think
the
changes
there
have
been
valuable
in
terms
of
improving
correctness
and
stuff,
but
yeah
the
breaking
changes
have
been
painful
for
a
lot
of
people.
It's
like
personally.
I
have
no
pro
problem
with
where
we
want
to
do.
You
know
if
we
want
to
do
the
development
on
that
particular
piece
and
do
it
in
a
separate
project.
E
E
So
if
this
can
be
done
in
a
way
that,
like
you
know,
ensures
that
there
is
a
really
good
process
for
like
okay
there's
a
breaking
change,
it
needs
to
be
reviewed.
It's
you
know,
even
though
it's
done
off
in
this
other
repo,
it
still
needs
ts.
E
You
know
that,
like
the
two
tsc
sign
off,
you
know,
review
and-
and
this
kind
of
thing
like
what
we
would
do
in
core
and
then
the
schedule
for
when
those
breaking
changes
actually
go
out,
needs
to
line
up
with
node's
lts
schedule
so
that
there's
things
don't
get
out
of
sync
there.
E
C
B
B
So
it's
like
giving
core
the
guarantees
of
stability
and
stuff
requires
significantly
more
work
than
the
people
that
have
been
currently
involved
in
streams
can
provide,
and
also
you
know
we
could
allocate,
even
if
we
did,
we
could
allocate
that
work
in
other
areas.
Of
course,
that
probably
need
more
work
anyway.
So
I
am
not
convinced
so
again,
I'm
not
it's
not
that.
B
I
think
it's
a
great
idea,
I'm
just
not
convinced
it's
the
right
use
of
development
time
that
we
have
right
now
again
if
there
is
people
that
are
willing
to
do
to
work
on
core
there's
a
lot
of
work
to
be
done
on
what
would
you
streams,
okay
and
that
needs
a
lot
of
work
and
iteration
and
because
the
the
process
that
james
is
describing
is
really
like
a
lot.
It's
significant
a
lot
of
significant
amount
of
work
to
to
make
it
to
to
do
so.
B
It's
the
reason
we
can
move
faster
in
indici
robert
is
because
we
don't
have
those
restrictions
and
basically
we
can
do.
Oh,
we
need
to
do
a
relay
release
and
we
just
send
a
message
on
that
and
we
it's
just
a
single
comment
away.
Okay
and
we
could
bump
a
major
instead,
we
just
want
to-
and
it's
not
a
big
problem
for
for
anybody.
B
B
Recommendation
right
now
having
two
projects
in
between
maybe
not
a
great
idea
also
anyway,
we
should
not
be
changing
streams,
not
core
streams,
apart
from
the
fact
that
we
plan
to,
but
that's
a
different
story,
sorry
colin
and
we
we
are
probably
going
to
do
some
additions
to
to
the
family,
not
breaking
changes,
though
admissions,
so
you
should
be
fine,
but
it's
there
is
some
stuff
that
I
have
been
that
we
have
been
planning
with
isaac's,
so
we
might
want
to
isaac's
mind
to
work
some
some
stuff
on
our
things
for
a
bit.
A
Okay,
I
think
there's
been
a
pretty
good
discussion
we
might
want
to
move
on
to
some
of
the
other
topics
could
can
continue
the
discussion
in
the
issue
as
well?
Does
that
make
sense
at
this
point,
or
should
we
spend
more
of
the
time
today
on
it.
A
A
I
think
reuben
you
opened
that
one,
I'm
not
sure
if
you
put
it
on
the
agenda,
but
do
you
wanna
kick
us
off
on
that?
One.
G
Yeah
sure
so
I
personally
recommended
to
open
up
a
new
module
that
is
explicitly
only
there
for
anything
that
has
to
do
with
string
formatting
so
involving
colors,
involving
whatever
format
you
have
with
util
inspected
so
on,
because
util
at
the
moment
is
pretty
overloaded
with
a
lot
of
different
things,
and
we
do
have
good
formatting
in
there.
G
We
spoke
on
the
collaborator
summit
about
and
the
necessity
pretty
much
of
further
coloring
support
in
node
core
directly,
not
only
for
the
users,
which
is
very
good
out
of
my
perspective
as
well,
but
also
for
note
core
itself
actually
that
we
are
able
to
easier
colorize
output-
and
I
said
okay,
I'm
fine
too.
I'm
happy
to
implement
that
and
I
went
ahead
and
wrote
some
code
which
in
the
end
has
a
very
similar
interface
or
actually
it
has
the
same
interface
as
child
does,
because
in
that
case
I
I
played
around
with
different
apis.
G
G
So
that's
why
I've
done
that
and
I
at
the
same
moment,
I
reached
out
to
zinder
zorhos,
who
is
next
to
josh
one
of
the
main
maintainers
of
chalk,
but
he
did
not
react
so
far.
I
don't
know
and
that
I
did
that
and
when
josh
saw
that
well,
he
thought
it
was
offending
because
the
same
api
from
the
interface
and
so
so
it
was
not
ideal.
Definitely
how
things
worked
out
because
and
we
obviously
do
not
want
to
harm
anyone
in
the
ecosystem.
G
That's
pretty
much
the
point.
There
was
a
big
discussion,
then
afterwards
about
how
things
worked
out
or
not
pretty
much,
and
that's
where
we
stand
at
the
moment,
so
I
reached
out
to
josh
who
was
who
felt
offended
definitely,
and
we
discussed
that
we
can
also
sit
together
and
discuss
how
we
can
and
pretty
much
progress
in
general
in
this
topic.
There
is
no
specifics
yet
and
we
didn't
get
to
it
yet,
but
I
thought
it
is
definitely
the
right
direction
to
de-escalate
things
to
to
find
out
a
way.
A
I
guess
I
think
I'll
just
add
it's.
It's
probably
related
to
the
other
issue
that
james
then
added
to
ask
that
we
add
to
the
agenda,
which
is
vendoring
in
namespaces.
A
I
guess
it
just
highlights
that
one
of
the
things
we
need
to
think
very
carefully
about
when
we
look
at
bringing
more
things
into
core
in
terms
of
you
know,
additional
api
is,
we
should
consider
overlap
with
existing
modules
and
impact
on
that
front,
which
you
know
thinking
purely
technically.
You
know
in
in
the
the
collaborator
summit.
A
B
B
We
should
give
some
a
little
bit
of
guidance
on
those
situations,
because
people
are
like
the
scenery
and
others
have
taken
us
a
significant
route
in
the
ecosystem,
but
the
ecosystem
is
not
essentially
followed
or
is
not
has
not
followed
completely
and
there
is
some
discount.
B
There
is
a
problem
there.
Okay,
I'm
not
wanted
to
say
it's,
but
it's
something
that
we
should.
I
think,
address
or
communicate
something
about,
because
it's.
B
The
numbers
tells
the
story:
okay,
so
people
are
now
now
that
npm
reports
version
they
download
for
intervention
number.
The
most
downloaded
version
of
chart
is
the
version
with
that
was
supported
by.
B
That
version
that
was
supported
that
the
asm
version-
sorry,
the
the
the
common
js
version.
Okay,.
B
I
understand
I
understand
the
problem,
I
it's,
I
understand
the
problem,
okay
and
it's
so
there
is
two.
So
I
think
that
is
true.
So
my
what
I
wanted
to
to
to
point
before
we
move
to
the
rendering
proper
and
so
on,
and
the
communication
of
it.
It's
that
we
have.
These
are
actually
two
problems
that
are
separate.
B
B
Just
to
give
you
her
a
hint
on
on
the
on
the
and
I'm
not
look,
I'm
not
saying
that,
but
I
think
we
should
say
something
okay
and
about
this
topic,
because
it
seems
that
reading
some
of
the
messages
that
they
were
posted
on
the
trial
that
the
recommendation
of
node
was
to
migrate
to
esm.
For
some
reason-
and
I
don't
think
we
ever
did
migrate-
everything
to
esm
and
stop
supporting
cjs.
B
E
B
That
was,
but
with
chuck
the
two
things
like
the
the
problem
here
is
that
the
two
things
we're
talking
about
chalk,
because
essentially
myself
as
the
first
user
of
chalk,
one
of
the
users
of
chuck,
as
was
basically,
I
felt
that
I
could
not
rely
on
this
module
anymore
and
therefore,
therefore,
what
should
I
use
now
and
it's-
and
this
is
a
problem-
that
a
lot
of
people
in
the
community
have
right
now.
B
E
B
Okay,
I
think
I'm
using
ourselves
I'll
take
an
issue
of
writing
hope,
I'm
taking.
I
will
open
an
issue
on
the
topic,
okay,
on
the
topic
of
esm,
specifically,
so
we
can
track
it
on
the
next
one
of
our
next
meetings,
because
I
think
there
is
some
mishap
on
on
the
on
the
topic.
Okay
and
we
need
to.
We
need
to
provide
some
some
level
of
guidance
to
popular
module.
Authors.
Okay,
that
you
know
please
support
both,
because
the
community
is
not
ready
to
move
yet
or
something.
E
In
continuing
with
you
know,
like
node
needs
the
colorization
right
we
need,
so
we
need
something
internally
that
would
kind
of
make
it
easier
for
us.
We
don't
have
to.
We
don't
end
up
duplicating
all
this
effort
must
work
now,
whether
or
not
we
go
off
and
implement
all
of
that
ourselves
expose
a
similar
api
versus
vendor
in
chalk
use
it
internally
and
oh
by
the
way
we
we
happen
to
make
it
available
right.
You
know
that
api
available
users
also,
I
I
think
it's
a
similar
conversation.
E
You
know
that
is
a
very
similar
conversation.
What
we've
done
with
indici
right!
You
know
we
don't
expose
him
to
yet
right,
but
we
do
it.
You
know
we
do
use
it
to.
You
know
for
something
node
needs
which
is
fetch,
so
maybe,
instead
of
going
off
and
implementing
all
this
ourselves
right
in
a
separate
module,
we
vendor
in
chalk,
we
use
it
internally
and
then
this
this
issue
that
we
you
know
we
talked
about
at
the
collaborator
summit,
this
vendor
namespace.
E
G
I
believe,
like
there
are
a
couple
of
things
here,
so
I
would
actually
even
create
such
a
module
even
without
calorization.
In
there
I
mean
we
do
have
colorization.
Actually
it's
just
not
as
nice
from
the
api
itself,
but
you
are
able
to
use
the
colors
which
we
provide,
at
least
from
the
ansi
codes
and.
G
We
and
like
about
exposing
the
direct
module.
I
believe
there
are
advantages
and
disadvantages,
because
sometimes
we
have
different
requirements
in
a
way
and
maybe
sometimes
also
existing
apis-
that
we
might
want
to
still
continue
to
work
with
or
like,
because
we
would
duplicate
some
functionality
at
some
point.
This
can
be
good.
This
can
be
bad.
G
G
Thing
that
a
lot
of
users
really
require-
and
these
things
should
be
out
of
my
perspective-
something
in
north
court-
it's
just
historically,
it
has
not
been
done
that
way,
and
now
we
are
in
the
situation
where
people
say
and
absolutely
fair,
hey.
You
know
we
have
something
and
now
you
come
along
and
do
this
something
same-ish.
E
So
why
why
don't
we
split
the
conversation
just
a
little
bit?
One
is:
do
we
want
a
separate
top-level
module
for
the
string,
formatting
functions?
We
already
have
that
they're
bundled
into
util.
That's
question
one.
We
introduced
that
module
export
those
functions
there
deprecate
the
ones
that
are
on
that
are
on
util
for
for
for
now
and
go
for
that.
Even
if
that's
just
a
doctor
deprecation
second
conversation
is:
do
we
need
a
new
color?
A
A
You
know
if
there
is
it's
neat.
I
think
it's
a
much
easier
decision.
If
it
is,
I
think
we've
got
to
factor
in
what
impact
are
we
having
on
what's
already
out
there
in
that
decision
right
and
how
we
do
it
and
because
we
at
least
have
to
explicitly
know
if
we're
going
to
cause
some
sort
of
pain
or
impact
on
that
front
and
and
make
a
decision
in
that
context?
At
the
very
least.
E
And
I
think
we
need
to
be
very
selective
here
in
terms
of
does
node
itself
actually
need
that
functionality
like
I.
I
don't
think
I
don't
think
we
should
bundle
anything
from
userland
that
node
itself
is
not
using.
So
just
bundling
something
just
for
the
sake
of
making
it
available
to
users
should
never
be
a
thing
we
do.
It's
got
to
be
something
node
itself
is
using,
so
it's
it's
there
already,
because
we
need
it
and
we're
just
going
to
expose
it.
E
A
I
guess
you
can,
you
know
like
in
the
case
of
the
of
colors
and
the
the
analogy
to
indici,
it's
like
there's
two
different
parts,
there's
one
part
of
vendoring
it
in
for
our
internal
use
versus
exposing
more
generally
right,
and
so
you
know
our
approach
could
be.
Yes,
we
vendor
something
in,
but
we
don't
expose
the
whole
thing.
So
it's
not
really
a
a
competitor,
but
we
just
you
know,
have
something
that
can
be
used
internally.
E
Yeah
and-
and
you
know,
go
back
to
the
the
ui
and
what
we
discussed
in
the
collaboration
with
that
vendor
namespace
right.
If
we
do
happen
to
have
this
thing
there
right,
whatever
version
we
ship
would
be
available
through
that
vendor
colon
namespace,
if
someone,
if,
if
it
doesn't,
if
someone
wants
to
make
use
of
it,
it's
there,
it's
available
right,
you
know,
but
the
if
they
want
to
pull
the
latest
thing
without
off
on
npm.
They
can
still
do
that
and
there's
no
conflict
there
at
all.
E
E
G
So
james,
you
said,
actually
there
were
two
things
two
questions.
I
brought
up
a
third
one
that
I
would
like
to
clarify
and
that
is
actually
implementing
or
figuring
out
a
process
how
to
approach
user
lan
module
authors
in
case.
We
want
to
implement
the
functionality
that
exists
in
username
and
is
widely
used.
E
A
If
we,
if
we
write
that
down,
we've,
got
a
much
better
chance
of
handling
it
as
optimally
as
we
can.
As
you
know
again,
we
can't
always
make
everybody
happy
all
the
time,
but
if
we
basically
say
here's
our
approach,
we
understand
what
that
is.
I
think
it'll
improve
the
you
know,
that's
what
we
could
do
to
improve
the
situation
and
flow
as
we
try
and
do
these
kinds
of
things.
G
I
believe
it's
good
that
we
figured
out
this
and,
like
I
personally
see
these
three
key
questions,
two
of
the
ones
that
james
just
brought
up
and
I
deserve
I'm
going
to
open
up
another
issue
for
the
third
one,
because
we
don't
have
that.
I
would
actually
like
the
the
issue
about
the
new
formatting
module
was
considered
for
pretty
much
the
existing
apis
already.
G
E
Yeah,
well,
you
know
the
second
one
would
be
specifically
for
colorization,
you
know,
do
we
vendor
chalk,
or
do
we
have
a
our
own
colorization
api
right
so
kind
of
what
are
the?
What
are
the
issues
there
and
we
can
use
that
conversation
and
to
kind
of
help
inform
number
three.
A
A
And
I
think
best
comment
is:
is
almost
a
little
bit
different.
Another
issue
we
should
talk
through
on
that
issue,
which
is
like
anything
we
expose
will
cause
some
additional
work.
Some
additional.
You
know
you
know
you're
behind
two
releases.
Why
haven't
you
shipped
the
latest
thing?
You
know
and
we'll
you
know,
and
and
so
we've
got
to
factor
that
into
our
decision
as
to
whether
you
know
that
makes
sense
too
or
what
the
criteria
is
and
that
kind
of
things.
E
Right,
so
you
know,
if
that
security
release
on
some
vendored
module,
happens
to
also
bring
along
breaking
changes,
and
we
end
up
having
to
deliver
it
in
a
an
lts
release.
What
you
know
you
know,
how
does
that
play
with
our
lts
strategy
right?
You
know.
E
I
think
that
if
we
do
the
vendored
modules
similar
to
what
we
do
with
experimental
apis,
we
have
to
basically
explicitly
state
that
vendored
modules
are
outside
of
our
december
major
or
somber
policy
with
regards
to
lts,
and
it
is
possible
for
vendored
modules
to
to
have
breaking
changes
in
updates
from
one
release.
The
next.
A
A
E
A
F
We
we've
been
well
using
the
word
vendor,
as
in
we
use
it.
We
vendor
in
acorn,
for
the
referral,
but
I
mean
we
don't
expose
it
outside
of
you
know
as
its
own
api
and
that's
not
in
the
node.
So
yeah.
A
Right,
that's
the
difference.
You
know
our
existing
dependencies.
We
generally
don't
just
re-export
their
apis
right.
We
use
them
so
that's
kind
of
a
different
usage.
I
think
the
vendoring
is
like
we're,
making
we're
planning
to
actually
expose
their
apis.
So
we're
now
subject
to
changes
in
those
right.
A
A
E
What
I
will
say
kind
of
most
comment
for
for
the
site:
number:
two,
like
vendoring
in
chalk,
there's
two
parts
to
that
right
to
implement
the
actual
support
we
need
in
node.
Maybe
we
do
vendor
in
the
you
know,
chalk
as
a
dependency
internally
not
exposed
use
that
to
implement
the
colorization
that
we
need
right.
G
That
was
actually
my
suggestion
in
the
pull
requests
and
that
I
open
up,
so
I
mean
it
only
exposed
like
a
partial
functionality
from
chalk
in,
in
fact,
yeah
they're,
like
chalk,
has
more
functionality
than
the
code.
I
wrote
and
I
did
add-
and
that
was
probably
one
thing
that
I
might
have
not
done
like
I
I
believe
I
added
it
in
a
comment
that
it
should
not
yet
be
exposed
to
users,
but
I
added
a
documentation
already
to
show
like
okay.
That
is
how
it
would
look
like.
E
A
A
I
Yeah
I
had
added
it
to
the
agenda,
so
I
I
don't
feel
strongly
about
the
pr
anymore.
So
I
closed
it.
So
if
anyone
else
feels
strongly
about
it,
you're
more
than
welcome
to
open
a
pr
trap
that
in
again,
okay.
A
A
I
did
tell
him
if
there
was
nobody
else
that
could
help.
I
would
probably
do
that.
So
I
don't
think,
there's
anything
discussed
this
week.
A
E
Yeah
added
that
agenda,
largely
you
know,
to
go
with.
You
know,
reuben's
question
about
the
the
colorization.
The
main
thing
that
it
needs
right
now
is
just
folks.
You
know
tsu
members
to
go.
Take
a
look
at
that
issue.
There's
been
a
few
comments
there
already
beth
raised
a
couple
of
some
really
good
points.
Just
needs
consideration
and
discuss
and
the
thread
so
please
go
take
a
take
sometime.
A
That's
it
yeah.
I
think
I
think
that
one
it's
like
we
need
to
figure
out
also
like
some
more
concrete.
What
would
it
look
like
because
that
might
get
some
more
specific
comments
like,
like
you
were
saying,
is
the
proposal
that
things
that
are
there
aren't
subject
to
our
lts
policy
or
not
that
that
kind
of
specific
part,
I
think,
would
drive
a
lot
of
good
discussion.
A
H
It's
related
to
i18n.
I
was
just
about
to
log
off
okay,
oh
yeah,
that
one
so
give
me
a
minute
here.
Discuss
amongst
yourselves.
A
H
Oh
yeah
yeah.
No,
this
is
going
to
take
there's
going
to
be
a
longer
discussion.
So
so
you
know
the
the
community
committee
had
the
you
know
like
right
now.
The
way
translations
happen
for
the
most
part,
is
people
submit
prs
to
the
website
repository
and
that
works
okay,
but
it
has
certain
obvious
limitations,
the
biggest
one
being
that
we
can't
translate
the
api
documentation,
because
that's
not
in
that
repo,
it's
in
the
main
repo,
so
they
had
set
up.
H
You
know
crowd
in
and
had
big
plans
and
everything,
but
it
all
petered
out
and
right
now
we're
kind
of
it
looks
like
in
this
issue
we're
kind
of
moving
back
into
that
phase
where
a
bunch
of
people
say
I
want
you
know
who
who,
who
you
know,
are
very
well
intentioned,
probably
very
competent,
probably
willing
to
be
very
hard
working,
but
also
don't
have
any
real
current
connection
to
the
project
are
all
you
know.
H
I
would
love
to
be
involved
in
this
effort
to
expand
translation
beyond
this
and
do
more
and
and
which
is,
you
know,
and
we've
sort
of
seen
these
things
kind
of
you
know
everybody
volunteers
and
then
it
kind
of
peters
out.
H
I
mean
we
kind
of
saw
that
with
other
things
that
I
won't
name,
because
I
don't
want
to
want
to
insult
the
people
who
who
did
the
who
did
hard
work
for
a
short
period
of
time,
and
so
since
there's
no
more
community
committee,
it's
basically
up
to
the
tsc
to
decide.
Do
we
want
to
encourage
this
and
sort
of
be
responsible
for
monitoring
it
and
care
and
feeding
and
making
sure
it's
successful,
or
do
we
want
to
say
we
tried
this?
It
didn't
work.
We
don't
do
this.
H
Sorry,
neither
wants
a
good
answer.
In
my
opinion,
they
both
suck
and
it's
going
to
require
a
little
bit
of
conversation
to
figure
out
what
we
want
to
do.
So
that's
that's
the
that's
the
context.
I
don't
know
if
anybody's
anything
they
want
to
add,
but
I
don't
think
we
can
really
have
that
conversation
here
today.
Yeah.
A
So
I
think
that's
a
good
framing
and
all
we
have
time
for
you
know
we
can
leave
on
the
agenda
to
talk
about
it
next
time.
If
we
maybe
have
a
little
bit
more
time
and
if
people
had
thought.
H
I'll
just
add
that,
for
you
know,
anybody
listening
or
read
the
myths
that
I
do.
150
percent
encourage
people
to
open,
localization,
slash
translation,
pull
requests
against
the
website
repository
for
website
content.
That
is
not
going
anywhere.
So,
let's,
let's
get
it
all
translated,
but
that
doesn't
help
with
api
docs.
Unfortunately,.
A
Okay,
so
with
that,
I'm
going
to
stop
the
stream
we'll
skip
the
strategy.
Can
use
finishes
for
this
time
since
we're
out
of
time
other
than
I'll
mention,
there's
a
pr
to
add
a
new
one.
So
if
people
have
a
chance
to
take
a
look,
that'd
be
great.
Otherwise,
thanks
for
everybody,
who's
been
on
the
stream
and
everybody's.
Please
take.