►
From YouTube: Package Maintenance Team meeting - 10 March 2020
Description
A
B
B
A
A
C
A
It's
I
mean
I
yeah,
so
no
Jess,
so
I
guess
like
100,
is
putting
on
my
sir
org
management
have
less
is
always
easier
than
more,
but
that
doesn't
mean
that
more
isn't
the
right
answer.
If
we
think
that
it's
the
right
answer,
so
the
benefits
I
guess
are,
if
they're
different
repos
people
can
clone
just
that
repo
right
as
opposed
to
having
to
clone
multiple
things,
are.
D
C
D
E
D
D
A
I,
don't
yes,
yeah
done
yeah
I
mean
if
it's,
if
it's
that
the
references
are
really
just
an
org
repo
and
that's
what
you
can
do
the
includes
on
then
that
seems
like
a
pretty
compelling
reason
to
say
we.
We
actually
need
a
repo
/,
because
while
you
could
work
around
that,
it
just
seems
that
so
many
because
we're
saying
hard
to
explain
harder
to
use
much
less
clear.
What's
going
on,
you
know
if
you
could
say
or
repo
/
file,
then
it
would
be.
Something
are.
E
E
C
Necessarily
work
that
way
so
there's
a
gate
of
actions
did
not
allow
a
path.
You're
saying
if
you
are
referencing
a
if
you
are
referencing
an
include
I,
don't
know
how
the
snippets
includes
work
on
github
actions,
but
if
you're
referencing
a
template,
the
thing
that
you
say
with
something
you
you
need
to
reference:
org,
repo,
okay,.
D
But
this
could
also
be
something
we
bring
up
with
them
and
say:
look
we're
trying
to
figure
out
what
the
best
way
forward
here
is
to
support
both
there.
They
were
really
responsive
on
their
github
issues.
I
haven't
seen
them
be
super
active
since
it's
sort
of
launched,
but
I
mean
they're
still
working
on
it.
So
we
you
know
if
we,
if
we
raise
it,
maybe
they'll
they'll
get
back
to
us
and
say:
oh
no,
there's
totally
a
way
to
do
that
worth
asking
at
least.
A
A
D
A
A
A
C
C
C
Unum
does
the
redirects
the
reader
it
right,
yeah
yeah,
probably
not
a
major
issue
there,
I
suppose
yeah,
okay,
I
just
quickly
checked
the
circle
CI
and
they
have
imports.
They
call
them
orbs
that
you
can
import
and
the
examples
that
they
give.
They
are
org,
slash,
repo,
so
yeah
I,
don't
know
if
you
can
reference
a
something
from
deeper.
C
C
Everything
so
my
thinking
was
that
it
would
be
useful
to
have
a
way
to
sort
of
have
a
common
shared
layout,
but
we
probably
can't
do
that,
given
that
things
like
getup
actions
and
and
and
and
circle
CI,
they
want
the
whole
thing
to
be
a
repo.
So
for
Travis
it's
it's
it's
very
simple
right
here
you
say
include,
and
then
you
give
it
a
file
name
and
the
file
name
can
say
something
like
all
of
these
versions,
starting
with
six
right.
C
So
you
say
that
in
the
filings
like
Raiders
name
six,
whereas
for
something
else,
they
would
probably
have
to
be
a
sort
of
a
different
convention.
So
I
don't
know
how
we
solved
that.
That's.
Why
that's?
Why
you
actually,
starting
with
a
meta
discussion
about
you,
know
what
what
goes
into
a
repo
and
Bora?
What.
E
I'll
definitely
do
that
and
part
of
the
reason
for
that
is
for
both
github
actions
and
Travis,
and
presumably
everyone
you,
you
have
a
branch
identifier.
Typically
you
don't
point
to
like
a
version
release,
which
means
your
master
branch
has
to
be
backward
compatible
forever.
So,
whatever
structure
we
agree
on,
we
like
effectively
are
committing
to
doing
that
for
eternity.
So
you
should
careful.
D
I
mean
there's
a
don't.
If
you
don't
follow
what
github
recommends
you
do.
That
said,
github
recommending
you
to
do
this
on
actions
is
sort
of
weird
and
it's
hard
I
think
for
most
folks
to
understand.
What's
happened,
so
people
might
do
it
wrong,
but
I
assumed
we
could
do
it
right,
which
would
at
least
never
have
anybody
using
master
they'd,
always
be
using
a
version
branch
over.
E
And
we
could
recommend
that,
but,
given
that
it's
that
the
default
and
the
easy
thing
to
do
is
to
pull
it
off,
master
I
feel
like
it's
wiser
to
treat
that
as
to
treat
it.
That
way
is
that
you
can
never
bump
the
major
which
is
fine,
I'd
like
we
could
always
make
a
new
repo
as
a
trivial
way
to
do
that.
E
A
C
A
A
Or
like
we
only
have
to
create
like
I'm
just
wondering
those
like
is,
it
makes
sense
to
ask
for
hey
we're.
We
want
to
cover
these
ones,
so
these
are
the
names
we
would
like
the
okay
to
do.
Rather
than
going
back.
You
know
then
later
saying:
oh,
we
want
a
new
one.
We
could
get
the
okay
for
a
number
of
them
and
then
just
do
one
at
a
time.
A
A
F
Are
there
cross-cutting
concerns
that
could
be
that
the
package
maintenance
team
could
kind
of
help
set
black
better
word
standards,
practices,
recommendations
across
some
of
the
various
you
know,
responsibilities
of
maintaining
a
package,
and
so
with
that
I
took
some
time
to
look
into
all
the
existing
content
within
the
repository
there's
a
lot
of
surveys
and
some
responses
from
projects
and
already
some
good
documentation
in
there.
So
one
wants
to
scroll
down
towards
the
bottom.
My
final
comment
in
the
quoted
section
was
essentially
proposing.
F
Well,
here's
here's
a
speculative
table
of
contents
that
could
act
as
a
governance
document,
and
so
what
I
was
wondering
was
you
know?
Could
we
use
that?
Well,
hey
what
did
folks
think
of
the
topics
themselves
in
the
issue.
In
terms
of
you
know,
cat
or
categorization
organization.
You
know
too
much
too
little,
but
also
not
wanting
to
reinvent
the
wheel,
since
there
is
a
lot
of
existing
content
in
the
repository
itself.
F
D
G
G
So
that
that's
pretty
something
that's
missing,
we
actually
look
at
our
read.
You
know
what
people
want
is
a.
This
is
how
you
do
it,
this
probably
fulfills
that
and
that
the
question
really
is
perhaps
not
do
we
do
we
need.
This
is
how
you
do
it,
but
had
we
had
restructure.
This
is
how
you
do
it
and
linked
into
the
other
things.
I.
Just
absolutely
think
you
know,
because
you
have
to
like
drill
down
toward
little
bits
of
markdown.
We
have
I.
A
Think,
like
in
the
docs
directories,
something
like
this
would
be
a
great
index
and
then
with
links
to
some
of
the
existing
ones
and
filling
it
like
you've
got
certainly
got
other
areas
which
we
haven't
covered
like
you
know,
I,
don't
think
we've
made
recommendations
on
a
code
of
conduct,
but
I
I
think
having
that
like
as
a
much
as
a
maintainer
here
or
all
the
here,
or
you
know,
the
general
list
of
things
you
have
to
worry
about,
and
then
here
are.
The
links
of
the
resources
we
have
is
would
be
very
helpful.
A
D
So
I'd
like
to
say,
I
think
this
is
this
particular
issue
has
gone
to
two
very
specific
topics,
both
of
which
I
think
are
good,
but
I
think
are
actually
two
separate
topics,
so
one
is
having
a
table
of
contents.
That
is
like
a
starter
guide
that
lists
all
of
the
different
resources
we
have,
which
I
think
would
be
great.
The
way
I
originally
read.
This
issue,
though,
is
a
different
thing,
which
is
having
specific
guidance
on
things
like
contributing
code
of
conduct,
governance
structure.
D
Right,
like
it
says,
governance
models,
so
I
was
thinking
of
things
like
how
node
says
its
governance.
Is.
You
know
this?
Here's
a
document
that
outlines
what
nodes
governance
looks
like
so
when,
when
I
was
working
on
doing
the
Express
application
for
the
you
know
foundation,
they
had
a
bunch
of
examples,
and
that
was
really
helpful
for
me,
because
I
had
no
idea
what
to
write
right,
so
I
just
copied
and
pasted
a
bunch
of
things
together.
D
A
A
F
There
are,
there
are
some
gaps
which
I
am
happy
to
help,
so
there's
some
and
draft
some
out
of
draft,
and
then
some
that
would
be
missing.
So
you
know
coming
up
with
that
index,
would
then
give
us
a
set
of
checklists
internally,
for
you
know
where
we
have
things
Bruce
about
supplement
things
and
and
yeah
they
also.
F
A
good
idea,
and
maybe
also
yeah
I-
guess
maybe
Wes,
could
you
just
for
my
own
personal
knowledge
and
from
your
experience,
if
you
were
to
put
together
like
a
couple
of
high
level
topics
for
a
governance,
talk
that's
different
than
this.
Just
to
help
give
me
a
good
direction
to
run
with
there.
So
I,
don't
believe
the
Alliance
again
sure.
D
B
A
So
right,
I
went
past
the
so
there's
a
there's.
A
governance
talk,
contributing
dark
code
of
conduct,
dark
these
kind
of
fit
into
like,
and
this
one
says
like:
okay,
what
are
collaborators?
How
do
people
become
collaborators
who's?
The
technical
steering
committee?
What
kind
of
process
do
we
use
to
make
decisions?
A
F
D
I
was
just
gonna
add
to
that
like
the
having
some
templates.
So
where
I
see
this,
our
value-add
right
would
be
having
some
templates
to
say
if
your
governance
style
is
benevolent
dictator
for
life.
Here
is
a
document
that
you
could
copy
and
paste
into
your
repo
to
codify
benevolent
dictator
for
life
governance
models.
If
your
governance
model
is
governance
by
technical
steering
committee
with
a
dissent,
you
know
based
thing
or
whatever
you
know,
I
guess:
I,
don't
know
how
paraphrase
what
nodes
is,
but
you
know
here's
the
document
you
could
copy.
D
A
Even
the
upfront
discussion
of
what
the
different
common
models
are,
because
it
sounded
like
you'd,
looked
at
a
bunch
of
different
different
projects
and
it's
like
okay
there's,
they
probably
fall
into
like
five
categories
or
something
right
and
then
having
a
template
for
each
of
those
categories.
That's
a
that's
a
good
resource
for
sure.
So.
F
D
D
A
D
D
It
would
be
helpful
if
you
were
like
bringing
on
new
contributors.
If
you
didn't
have
to
spend
hours
researching,
how
do
I
have
a
technical
committee?
What
does
that
even
mean?
Is
there
a
definition
that
I
could
just
follow?
So
it
is
day-to-day
running,
because
that's
how
you
run
the
project
right
like
we
have
this
group
and
that
group
meets
and
just
like,
we
have
a
group
that
that
meets,
and
you
know,
although
we
don't
have
like
technology
decisions
to
make
per
se,
you
know
we.
D
A
We
don't
have
oneness
we're
not
formally
a
working
group.
Any
of
the
node
working
groups
need
to
have
one
that
says:
here's
our
governance
in
terms
of
like
how
do
you
join
the
teams
and
stuff
like
that,
but
there's
no
reason
why
we
couldn't
you're
right.
We
did
capture
some
of
that
in
the
readme
in
terms
of
like
how
to
join
and
stuff
like
that.
F
F
Just
I
guess
in
for
nothing,
everybody
has
to
answer
right
now,
but
would
also
be
curious,
just
thoughts
in
general
on
the
items
and
topics
an
organization
of
sample
table
of
contents.
If
there's
anything
missing
too
broad,
you
know
things
are
in
the
wrong
place
or
anything
like
that
could
also
be
helpful
that
we
can
all
work
on
that
together,
but
for
in
your
free
time,
I.
A
A
D
F
A
C
C
I
have
a
pull
request
open
on
of
keeping
dependencies
up
to
date,
which
is
not
node
itself.
It
does
reference
node
and
and
how
you
do
that
so
I
have
a
doc
open
for
that
or
request.open.
For
that
there
are
some
pending
comments
there,
which
I
have
to
address,
but
otherwise
yeah
feel
free
to
add
something
there.
C
D
I
might
not
have
time
super
soon,
but
I
have
been
working
on
an
internal
dock
for
how
we're
gonna
do
this
and
I'm
sure
I
could
copy
and
paste
things
out
of
that.
If
there
was,
you
know
a
place
to
put
them
I'm,
not
I'm,
not
Bob,
to
be
clear:
I'm,
not
volunteering
and
starting
the
dock.
I
don't
have
time
for
that,
but
I'd
be
happy
to
the.
A
A
D
A
A
Yeah
we
haven't
heard
I
mean
Tierney's
hadn't,
had
a
number
of
questions.
I
haven't
heard
like
made
your
opposition
or
anything,
but
maybe
in
like
the
in-person
discussion,
we
can
get
a
little
bit
more
clarity
on
our
people.
Just
like
yeah,
not
commenting
cuz,
it's
fine
or
there's
you
know
or
there's
any
concerns
that
are
slowing
it
down.
I.
D
Agree,
it's
a
little
hard
to
say,
but
I
also
would
be
interested
to
know
if
this
group
is
like
super
behind
this
because
I
know
Tom
and
I
have
been
committing
to
those
repos,
but
not
everybody
else
has
so
and
I
know
Darcy.
You
mentioned
you're
in
support,
if
nothing
else
just
to
house
the
NP
eminent
creation
stuff,
but
is,
but
nobody
else
has
commented
on
this
issue
so
either
either
support
would
be
helpful
or
good
dissent
for
why
you
know.
Maybe
we
could
do
this.
B
A
We're
a
team
T
I
mean
day
to
day.
It
really
makes
little
difference
the
the
main
difference
as
a
working
group
is
formally
delegated
responsibility
for
something,
whereas
as
a
team
we're
just
getting
together
and
working
on
something
and
we
haven't
been
delegated
responsibility
from
the
TSA,
but
really
doesn't
make
a
difference
right.
C
Yeah
I
think
that's
a
thing
right,
I
think
that's
also
an
important
distinction
in
the
perspective
of
the
separate
repository,
because
it
is
the
same
as
you
know
getting
together
and
writing
some
code
versus
being
delegated
a
responsibility
to
actually
produce
certain
things.
In
the
name
of
the
foundation.
C
B
It
just
kind
of
blurs
the
lines
if
we
create
some
set
of
tooling
and
then
write
a
blog
post
on
the
node
blog
about
it
like
is
that
essentially
blessing
that
tooling
and
and
then
yeah
when
when
does
the
experiments
become
or
that
org
anything
that's
living
in
that
order
owned
by
that
or
become
so
popular
or
so
you
know,
depended
upon
that,
then
you
know
there's
a
concern
in
how
we're
operating
or
what
you
know.
I,
don't
know
when.
D
It
would
it
help
to
resolve
that
concern
if
we
made
some
explicit
governance
doc.
That
said
at
a
point
where
this
you
know
we
deemed
this
popular
or
dependent
on
enough,
we
would
move
it
into
the
node
org
and
it
would
be
considered
more
stable
and
or
something
like
that,
where
we
could
still
keep
nice
experimental
nature
where
we're
doing
sort
of
you
know
working
out
the
details
of
what
we
might
be
working
on,
but
still
have
like
I.
Think
somebody
mentioned
having
like
a
gradual
raishin
step.
A
C
Think
I
think
the
other
concern
I
do
have
there
of
putting
it
into
the
node
organization
is
discouraging
people
from
competing
with
it,
because
once
you
put
something
in
an
official
node
repo,
they
will
say:
oh
well,
node
has
this
and
I
don't
need
to
build
this
or
I.
Don't
want
to
build
this
I
don't
want
to
compete
with
it
because
they
have
the
whole
foundation
behind
them,
which
is
not
necessarily.
C
G
G
See
where
we
put
the
stuff,
but
eventually
the
outcome
of
this
is
what
we
have
a
way
we
can
go
into
express.
We
can
help
out,
we
can
triage,
we
can
have
repo
captains,
we
can
go
in,
we
can
do
it
Axios,
we
can
help
our
projects
and
there
is
a
blessed
methodology
with
an
indexed
or
MD
for
contributing
and
so
forth
that
people
can
follow
up,
don't
have
to
follow
it,
but
all
we
can
say
so.
We
tried
this
and
it
worked
at
some
point.
We
graduate
so.
D
I
guess
what
I'm
sort
of
it's
may
be
subtle,
what
I'm
disagreeing
on
so
I
general
I.
Think
yes,
I,
like
that,
having
some
methodology
that
we've
said
yes,
it
works
is
good.
Where
I
see
this
org
going
in
slightly
different
direction,
is
some
of
these
things
might
be
sort
of
tangential
to
that
process
right?
So,
if
you
look
at
what
we've
put
in
there
now
like
I,
think
the
status
board
really
has
nothing
to
do
with
that.
I
think
detect
notes.
Support
might
have
something
to
do
with
that
at
some
point
right.
D
D
I
put
a
couple
of
repos
in
here,
Envy
I
think
is
one
where
maybe
we
do,
because
I
mentioned
to
Jordan
I've
been
in
the
and
VM
repo
trying
to
get
some
actually
cross-cutting
support
for
these
aliases
I
think
would
help
folks,
but
like
pretty
much
the
rest
of
it,
no
I.
Don't
know
I,
don't
see
ever
a
reason
why
this
would
quote-unquote
graduate
to
you
know
no
thing
future
things
maybe
but
I
think
what's
in
here
today
is
is
a
pretty
much
mixed
bag.
A
Yeah
I
mean
as
we're
talking
about
it's
kind
of
like
at
what
point
will
you
know
if
it's
another
org
owned
by
the
node
project?
Do
you
get
up
that
if
that's
truly
concerned
you're
in
the
same
you're
in
the
same
ballpark
right
like
it's,
it's
kind
of
hard
like
we
want
to
take
advantage
of
the
benefits
of
being
part
of
the
larger
group,
but
not
the
not
some
of
the
things
that
come
along
with
that
in
terms
of
like
well,
it's
because
we're
leveraging.
A
You
know
the
code
of
conduct,
the
the
moderation
team
and
all
that
the
other
thing
that
comes
along
with
it.
People
look
and
say:
oh
well,
the
note
projects
working
on
that.
So
it's
got
a
little
bit
more
credibility
right,
but
I'm
not
sure
in
the
end.
Will
it
be
any
different
right
if
there's
lots
of
stuff
in
there
and
there's
lots
of
activity,
it's
almost
the
same
thing.
D
And
to
be
cooler,
that's
not
necessarily
a
bad
thing
like
having
a
bit
more
credibility
is
actually
a
good
thing,
because
if
you
look
at
what
this
group
might
produce,
the
hope
would
be
that
it
would
be
of
materially,
better,
maybe
not
quality,
but
support
ecosystem
friendliness
following
best
practices.
And
if
you
compare
that,
just
to
the
average
random
repo
you
might
find
in
theory,
we
should
produce
something
a
little
bit
more
standardized
right.
A
Yeah
I
guess
I'm,
like
I,
don't
have
a
strong
feeling,
one
way
or
the
other,
so
we'll
we've
got
the
issue,
we'll
try
and
get
some
more
discussion
in
the
meeting
tomorrow
and
see.
If,
if
you
know
the
the
TC
members
are
like
yeah,
that's
not
a
problem,
we
should
just
do
it.
Then
we
can
take
it
from
there.
Cuz
I
mean
I.
I
can
see
in
terms
of
like
the
node
project.
You
know
having
different
namespaces
would
almost
be
useful
in
some
cases,
but
you
know
you
sort
of
go
into
here.
A
You
know
you
like
I,
almost
wonder
if,
like
if
we
had
like
an
OGS
experimental
namespace
that
adds
in
the
it's
tied
to
the
node
project,
but
this
is
all
experimental
stuff.
So
you
know
it's
something
like
that
and
then
that's
a
more
generic
concept
that
would
maybe
be
applicable
in
other
cases
too.
I
don't
know.
A
It's
like
something
like
that:
there's
certainly
a
readme
for
every
one
which
should
make
it
clear.
You
know
what
the
repos
for,
and
we
have
quite
the
range
like
from
internal
tools
that
we
just
use
ourselves
to
generate
meetings
to
things
like
an
API
that
we
use
to.
You
know
the
note
add-on
API,
which
is
something
that
people
actually
use
in
their
applications
to
internationalisation
repo.
A
A
Needs
to
be
approved
by
or
it
needs
to
not
be
objected
to
by
the
calm,
calm
and
TSC.
So
you
know
the
those
members
look
at
it
and
say
is
that
you
know
fitting
with
what
we're
doing
in
the
project.
So
if
it's
something
that
is
either
a
group
already
working
in
the
project,
it
kind
of
think
makes
sense.
If
somebody
came
from
outside
and
said
I'm
doing,
something
completely
different
doesn't
relate
to
know
what
I
think
they'd
probably
say
just
make
sense
right.
A
A
B
A
Sorry,
the
request
of
the
TSE
was
another
organ
to
the
project's
auspices,
because
the
ask
was
for
like:
can
we
get
it
to
be
covered
by
the
moderation
right
and
the
code
of
conduct,
and-
and
you
know
as
soon
as
you're
asking
the
project
to
own
it,
then
it's
gonna
need
to
have
something
that
says.
Well,
how
do
you,
if
you
want
to
be
a
different
org,
you're
different
or
you
can
do
whatever
you
want
right
so.
B
A
B
A
B
D
Think
it
would
be
great
to
add
in
a
set
of
alternate
proposals
to
this
discussion
before
the
meeting.
It
would
be
I
think
in
the
the
best
edition
that
I've
heard
would
be
instead
of
pkg
J
s,
creating
a
knowed
experimental
or
some.
You
know
variant
of
that,
because
that
to
me
speaks
more
broadly
to
the
project
and
I
think
that
might
actually
get
people
more
on
board
have
more
applicable,
'ti,
more
value
in
the
long
run.
That's.
A
D
B
B
D
Agree
and
I
would
actually
be
fully
on
board
if
we
just
changed
the
whole
require
us
to
be
actually
we'd
like
to
make
a
note,
experimental
thing
and
move
things
like
the
quick
work
into
it
and
anything
else
where
you
know
it.
It's
not
quite
ready
for
primetime
I,
think
that
would
make
a
strong
argument.
So,
okay,.
D
Other
thing
that
maybe
is
sort
of
questionable
here
for
so
again,
maybe
we
choose
not
to
move
all
of
the
work
that
exists
in
that
pkg
pkg,
Jess,
cuz,
I
think
that
would
be
a
good
idea
if
we
went
with
this
proposal,
but
also
wouldn't
this
D
legitimize
some
of
the
work
where
it
might
be
like
not
experimental,
but
it's
just
not
no
js'.
All
right
like
this
is
like
a
shared
CI
config
you
can
make
a
strong
agreement
is
not
no
js'
right.
It
is
not
part
of
the
node.js
project.
B
E
B
E
B
E
Mean
that
for
I,
don't
think
this
is
great
I
mean
I,
think
the
slippery
slope
argument
doesn't
have
to
hold.
If
we
just
say
this
is
what
makes
sense
for
this
specific
working
group,
because
this
one,
unlike
most
of
the
others,
is
dealing
with
the
ecosystem
and
not
node
directly,
whereas
almost
all
the
other
working
groups
are
dealing
with
node
in
the
ecosystem
right
and
like
so
this
is
a
unique
case.
The
version
management
working
group
deals
with
node
right.
It
doesn't
deal
with
NPM
modules,
things.
E
We
build
a
tool
that
node
starts
utilizing
and
at
that
point
it
should
be
transferred
but
to
probably
be
transferred
into
the
node
org.
That's
also
easy
to
github
maintains
all
the
redirects
like
that,
and
that
is
the
correct
signal
that
means
at
this.
At
this
time
and
not
prior,
it
is
now
part
of
node,
instead
of
just
being
something
that
node
people
are,
are
managing
separately
yeah.
B
So
I
think
we've
discussed
that
as
well
in
this
conversation
right
like
like.
Maybe
it
makes
sense
to
outline
what
it
looks
like
to
promote
or
bless
or
like
have
something
be
brought
in.
That's
why
I
asked
specifically
for
what
the
criteria
was
for
something
to
be
brought
in
right
like
it's
like
what
is
that?
What's
the
gating
factor,
and-
and
maybe
it's
exactly
what
you're
saying
right
Jordan,
maybe
it's
it's
yeah.
E
Yeah
I
think
that's
the
whether
whether
consumes
is
ships
as
part
of
the
Corps
or
whether
consumes
as
uses
as
part
of
the
build
process.
I
mean
when,
when
node
can't
work
without
a
tool
we've
built,
it
should
be
a
node
tool,
but
when
it's
just
people
that
use
node
that
benefit
from
those
tools,
then,
like
that's
part
of
our
purview
more
hopefully
no
more
than
node
course
yeah.
B
A
E
Mean
you
can
see
the
argument
in
lots
of
directions
right
but,
like
I
mean
nvm
was
never
permitted
to
join
the
node
foundation,
because,
even
though
it
was
part
of
the
ecosystem
and
a
good
fit,
there
was
worried
about
blessing
tools
and
there
was
worry
about.
Well,
it's
not
actually
node
core,
and
you
know
so
on
and
so
forth,
and
this
to
me
feels
similar
in
that
like
if
node
is
no
cores,
not
consuming
them,
then
like
whether
you
could
make
it
work
or
not.
I
mean
it's
it's
the
burden
of
adding
an
organization.
B
I'm,
just
I
want
to
make
sure
that
it's
like
very,
like
I'm,
very
aware
of
what
I
can
and
can't
contributor
what
we
can
and
can
cannot
contribute
to
the
node
org
for
whatever
reason
right
like.
If
that
is
a
gating
factor
and
there's
you
have
to
meet
X,
Y
and
C
to
put
a
project
into
the
node
or
go
just
wanna,
make
sure
that's
outlined
in
the
docs
right.
Yep.
A
Even
requirements
for
any
dot
I
mean
the
discussion
back
to
nvm.
It
was
more
like
you
know
it's
it's
kind
of
different
between,
like
the
team,
the
the
communities
building,
something
for
use.
You
know
like
I,
guess
we
are
building
things
because
we
don't
see
a
solution
to
it.
That's
out
there
and
we're
making
those
available
and
we
need
a
place
to
do.
It
is
different
than
pulling
in
one
of
the
three
competing
options.
Right,
I
think.
B
It's
also
helping
to
set
a
standard
and
define
good
practice
like
that's
what
we're
trying
to
do
here,
which
essentially
is
saying
you
know,
come
to
this
table
and
you
can
help
define
what
those
standards
are
and
this
this
table
is
in
some
sense
blessed
by
the
network.
So
then
those
standards
and
whatever
tooling,
should
also
get
the
same
level
of
I
mean.
E
E
I
hope
they're
the
best
solution,
but,
like
you
know
the
it
would
be
foolish
to
deny
the
the
PR
impact
of
that
and
I
think
that
here
we
have
the
opportunity
to
develop
things
in.
You
know
with
less
of
that
artificial
boost,
you
know,
to
kind
of
vet
validate
to
ourselves
that
this
is
in
fact
the
right
solution
is
at
the
point
where
we
moved
into
the
node
org.
It's
it's
done
right
like
it's
there
and
now
it's
calm
and
j/s,
and
it's
there
forever
right,
like
it's
a
thing
so
like.
A
E
They're
so
then,
then
we
can
transfer
all
the
repos
in
and
and
our
or
great,
like
all
the
redirects
will
work,
and
you
know
it
will
be
as
if
the
org
never
existed
right,
but
that's
a
that's
a
bunch
of
ifs
and
in
general
I
find
it
easier
to
consolidate
them
to
separate.
So
I
would
prefer
to
err
on
the
side
of
over
separation.
A
A
A
C
A
B
A
A
Cuz
I
mean
I
think
we
quickly
get
to
the
point
where
it's
like.
Well,
this
really
is
an
experimental,
it's
just
so,
okay,
we
have
two
other
issues
tag
but
we're
out
of
time
so
document
current
top
10
Express
issues
and
next
steps
on
level
and
package
support
for
package.json.
Is
there
anything
we
need
to
mention
on
those
before
we
close
out.