►
From YouTube: KEYNOTE: Contributor Panel- James Snell (Moderator), IBM
Description
KEYNOTE: Contributor Panel- James Snell (Moderator), IBM; Bryan English, Intrinsic; Anna Henningsen, Student; William Kapke, Kap Co; Jeremiah Senkpiel, NodeSource
A
B
B
Okay,
how's
everyone
doing
good
all
right,
so
I'm,
James
snow
I
am
one
of
the
core
contributors
to
node
I'm
work
for
IBM,
but
this
is
not
about
that.
We're
talking
about
a
node
core,
contributing
the
node
core
and
before
we
get
started.
One
thing
I
will
say:
I
have
a
few
questions,
but
I
really
want
to
get
questions
from
all
of
you
as
well.
There
is
a
couple
of
microphones
in
the
back.
If
you
can
all
just
you
know,
those
of
you
have
questions
queue
up.
B
If
you
don't
come
up
with
questions,
I'm
gonna
start
coming
up
with
some
random
stuff.
That
has
nothing
to
do
with
node.
So
you
know
just
you
know,
like
you
know
what
is
the
color
blue
sound
like,
so
you
know
come
up
with
some
some
questions
and
we'll
go
from
there,
but
before
we
go,
let's
have
I
want
to
treat
themselves
starting
with
Jeremiah,
hey.
C
D
E
F
My
name
is
William
Koepke
aka,
william
cap,
key
I'm,
everything,
let's
say:
I
I
am
off
to
I,
observed
that
the
tsc
meetings
I
am
not
eligible
to
be
on
the
tsc
because
of
weirdness
we're
trying
to
work
out
to
get
more
people
eligible
to
be
on
there.
It's
just
like
a
legal
kind
of
thing
or
something
I,
don't
know,
and
yeah
I
kind
of
buzz
around
and
bug
them
to
like
change
little
things
that
are
not
like
the
spotlight
cool
stuff.
B
Excellent,
thank
you
all
for
joining
us.
First
of
all,
so
there's
a
number
of
things.
I
wanted
to
talk
about.
One
of
the
things
is
with
node
one
of
one
of
the
key
issues
that
we've
been
struggling
with
with
core
lately.
Is
this
question
of
relevancy
versus
stability
right?
So
when
can
we
take
new
features?
You
know
where
you
know:
when
can
we
deprecated
things
or
you
know?
When
do
we
just
need
to
not
touch
things
and
just
leave
it
alone?
So
we
don't
break,
you
know,
have
to
plan
it.
B
F
F
They
laugh
because
they
they
up
their
list
in
their
head
of
like
a
okay
and
those
are
those
are
kind
of
the
onesies.
You
know
really
focusing
on
here
I
think
in
this
question,
because
some
do
break
in
how
bad
does
it
break
and
how
many,
and
when
do
we
stop
saying
this
group
is
a
bigger
voice
than
that
group
and
and
make
a
decision
right.
So
yeah.
B
111
very
important
example
of
this
has
been
the
changes
to
buffer
right.
You
know
we
were
in
the
year
we
made
some
changes
introduced
new
buffer
api's,
because
Tucker
api's,
and
we
decided
that
we
wanted
to
move
people
away
from
using
the
buffer
constructor,
and
we
had
it
added
a
deprecation
to.
If
you
don't
use
new
buffer,
it
throws
a
deputation
message,
mrs.
B
cause
the
number
of
victories
I
was
wondering
if
you
could
kind
of
comment
on
your
thoughts,
because
we
recently
just
revoked
that
change,
and
you
were
a
significant
part
of
that
discussion
and
kind
of
guide
it
forward.
You
have
any
my
thoughts
currently
on
that,
where
we're
at
and
well.
E
I
mean,
I
guess
my
car
mostly
that
we
really
need
to
get
better
at
messaging
stuff,
like
like
the
biggest
problem
with
that
identification,
warning
that
we
did
in
v7.
What's
that
like
it
did
neither
have
the
effect
we
wanted
it
to
have
didn't
move
people
actually
actually
move
people
away
from
the
buffer
constructor.
E
Nor
was
it
messaged
as
a
security
feature
which
is
like
the
purpose
of
the
warning
was
to
inform
users
the
terrace
a
potentially
unsafe
feature
in
their
code,
even
if
they
use
it
through
three
layers
of
nested
modules
and
so
yeah
I
think
that
was
mostly
a
messaging
fairly.
Another
will
not
one
about
change
itself.
I
mean
I.
That's
my
personal
opinion.
Sin
right,
I!
Guess
what
there
there's
good
reason
why
module
authors
have
a
different
view
on
that
and
yeah
right.
B
C
Mean
yes,
so
that
that
was
one
example,
but
there's
there's
multiple
different
ways.
This
can
happen
and
sometimes,
as
previously
happened
with
buffer
I,
think
for
before.
Actually
sometimes
our
dependencies
move
in
ways
that
were
forced
to
react
to
that
on,
and
that
could
still
happen.
It's
always
always
kind
of
a
thing.
C
So
in
that,
in
that
kind
of
case,
we
might
still
need
to
do
something
in
a
mark,
speed,
xpd,
ated
way,
but
I
think
it's
definitely
like
really
important
for
us
to
always
keep
trying
to
be
more
and
more
on
top
of
the
ball
as
to
like
what
the
ecosystem
usage
of
anything
is
to
gauge
impact.
C
D
Mean
the
only
thing
that
I
would
add
would
be
that
whenever
some
kind
of
change
like
that
is
going
to
come
through
it,
when
it's
gonna
be
like
removing
something
blatantly
breaking
something
like
an
adequate
scan
of
the
community
is
kind
of
necessary
and,
like
Nikita,
has
been
useful
for
that,
for
example,
chalker
so
I
mean
that
that
I
think
is
extremely
important.
Just
like
examining.
G
C
And
I
just
want
to
reinforce
that
we're
always
going
to
do
our
best
to
make
sure
that
anything
that
like
is
even
potentially
breaking
that
way.
Even
if
throwing
downstream
depends,
he
or
whatever
is
always
going
to
happen
in
a
major
version
on
anything
that
doesn't
I
mean
like
if
it
happens
in
a
minor
patch
like
it's
saying
that
we
need
to
revert
right
away
right.
B
And
one
thing
that
I
that
I
appreciate
is
the
fact
that
you
in
the
staples
for
a
real
calm,
stable
and
the
currents
we
have
demonstrated
that
when
the
when
breakage
does
occur,
and
it
becomes
obvious
that
we
are
willing
to
revert
those
like
this,
like
the
new
buffer
thing.
So
the
flip
side
of
this
question
is:
can
we
ever
add
anything
to
core
like
and
I
know
Jeremih
you're
you're?
You
know
performing
at
the
real
small
core
philosophy
right.
B
C
Feel,
like
I,
am
not
really
like
one
of
the
people
that
really
wants
it
like
super
small,
but
like
I,
don't
I,
don't
think
it's
necessarily
helpful
for
us
to,
like
just
add,
like
the
bucket
list
of
everything
we
have
a
great
community.
That
already
like
has
an
ecosystem
just
about
everything.
So
I
think
we
should
be
more
about
like
enabling,
like
as
many
use
cases
as
possible
from
like
a
low
level,
but
like
a
usable
level,
still
yeah
all.
B
Right,
okay,
so
I
want
to
switch
to
a
different
topic
with
things
like
I
think.
All
of
us
here
are
actually
relatively
new
to
contributing
to
to
note.
You
know,
then,
the
past
year,
two
years
right
around
in
there
there's
been
a
significant
effort
late
with
things
like
the
co
learn
in
the
node
together,
and
you
know,
varieties
of
these
community
outreach
efforts
to
attract
new
contributors
to
core
and
to
note,
and
not
just
core
I
mean
I
all
aspects
around
node
and
two
to
mentor
new
contributors.
B
Those
efforts
seem
to
be
effective.
Like
we're,
you
know
we're
getting
lots
of
new
contributions,
but
what
can
we
do
to
kind
of
continue
those
efforts
and
grow
and
improve
on
those
efforts
over
the
next
over
the
next
year?
I
just
art
in
a
way
Madonna
at
least
two
of
them
speaking
for
a
little
bit,
should
hear
from
me
to
a
little
bit.
Okay,.
F
So
when
I
was
getting
involved
and
trying
to
figure
out
what
was
going
on,
I
came
across
repo
on
github
called
code
and
learn
and
doing
of
my
research
on
what
is
this
thing?
I
believe,
if
I
remember
correctly,
it
was
something
that
was
hatched,
maybe
at
the
collaborator
summit
last
year,
or
something
to
that
effect.
G
F
A
brilliant
idea
like
yes,
let's
do
that
and
then,
when
I
saw
how
old
the
issues
were
in
there
I'm
like
Hello
somebody,
please
revive
this
and
I.
Don't
know
if
I
kick
that
up
or
it
may
be,
helped
it
along
and
maybe
bring
his
top
of
someone's
email
but
inbox
or
something
like
that
and
front
of
the
mind
right.
F
But
then
it
did
happen
and
we
had
it
in
Amsterdam
and
it
was
really
awesome
and
we're
now
doing
it
following
this
event
and
like
they
had
there
were
so
many
people,
so
many
of
you
that
signed
up
they
had
to
actually
close
it
down,
because
we
we
didn't
have
enough
space
for
everyone
so
like
they
went
from
dead
repo
to,
like
you,
guys,
filling
up
the
room.
So
it's
pretty
awesome.
Yeah.
B
I
know
that
you
know
onymous,
you
played
a
big
role
in
setting
up
the
couldn't,
learn
event
in
Amsterdam
in
in
that
one
event,
we
had
the
most
new
pull
requests
opened
against
node
in
one
day
in
its
history.
Now,
a
lot
of
more
small,
which
was
perfectly
fine,
I
mean
that's
the
point,
but
it
was
the
huge
amount
of
engagement
and
I
think
you
did
a
fantastic
job
on
organizing
that
you
know
at
after
going
through
that.
What
would
you
do
differently
in
terms
of
improving
you
know,
would
you
you?
B
E
H
E
G
E
B
There's
a
lot
of
just
deep
institutional
knowledge
of
what
node
is
that
is
tied
up
in
two
individuals.
You
know-
and
we
were
just
talking
about
this
a
little
bit.
You
know
the
hallway
that
even
among
some
of
the
core
developers
have
knowed
there's
there's
a
lot,
that's
undocumented,
and
you
know
those
of
us
that
get
into
you
know
doing
things:
the
native
layer.
We
look
at
pieces
and
like
yeah,
we
have
no
idea
how
this
works.
So
we
have
to
go
talk
to
a
single
person
right.
C
We
still
do
need
to
improve
like
documentation,
not
necessarily
I
mean
we
always
need
to
like
improve
our
API
documentation
to
and
have
like
guides
how
people
can
use
it,
but
I
mean
we've
worked
on,
let
this
like
a
little
bit,
but
not
not
really
nearly
enough
honestly
to
like
actually
document
like
why
certain
things
are
like
done.
The
way
they
are
in
no
dress
itself
in
the
code,
in
how
certain
algorithms
working
at
certain
structuring
yeah,
that's
something
that
we've
gotten
still
need
to
really
work
on.
Ny.
B
So
yeah
I'll
only
seam
lines
with
documentation
just
getting
information
out
there.
Mentoring
is
definitely
an
essential
part
of
growing
this
community
and
yeah
we've
we've
had
things
like,
you
know,
node
school
for
just
learning
note:
we've
had
you
know,
there's
a
node
live
and
there's
no
together,
there's
a
variety
of
community
efforts
that
are
just
built
around
building.
An
awareness
of
what
note
is
how
it
works
like
that.
B
C
I'm,
not
really
sure
I,
think
I,
think
everyone
kind
of
like
plays
a
role
in
to
that
because,
like
it's
kind
of
like
the
Foundation's
job
in
a
way
to
like
keep
this
thing
alive
in
that
sense.
But
it's
I
think
it's
also
like
our
duty,
as
like
core
team
members
to
to
pass
on
like
that
information
and
make
sure
that,
like
new
people
can
always
I
get
involved
and
really
kind
of
like
understand,
like
the
processes
around
the
project
and
like
also
how
like
the
project
is,
is
like
built
in
its
internals.
F
B
I
mean
you
mentioned
it's
often
time
you
know
easier
to
point
out
what
what
didn't
go
right
right.
You
know
and
we've
made
a
lot
of
changes
to
our
contribution
process.
Over
the
you
know,
the
past.
You
know
year
and
a
half
since
the
foundation
was
launched.
You
know
where
the
number
of
contributors
I
want
to.
You
know.
I
know
rod
in
his
his
talk
coming
up
soon,
he's
gonna
be
talking
about
some
of
the
numbers
that
we're
seeing
in
court
or
the
contribution.
B
So
I
don't
want
to
step
on
his
a
thing
too
much,
but
we're
saying
a
lot
of
growth
and
new
contributors
right.
But
retention
has
been
an
issue
getting
folks
to
come
back
what
parts
of
our
process
right
in
terms
of
how
we're
engaging
with
the
with
contributors
and
with
each
other
they'll
people
that
have
been
there
for
a
while
need
to
improve?
What's
not
working
there,
that
we
need
to
continue
iterating
on
an
approving,
so.
E
We
have
the
situation
with
readable
screen,
which
is
a
NPM
module,
which
is
basically
an
exact
copy
of
the
screams,
module
and
node
car,
and
there
were
some
people
proposing
that
we
pull
in
the
the
screams
repository
visit,
the
screams
module
in
car
from
readable
screen
and
make
do
all
of
the
work
there
so
that
we
have
one
central
place
where
only
screams
happen
and
where
people
can
engage.
Who
are
interested
in
that?
Who,
who
who
are
invested
in
that?
E
B
C
One
of
the
things
like
we've
improved
on
this
in
the
past,
but
like
it's
just
kind
of
always
saying
that
that
kind
of
comes
up
and
plan
needs
to
be
be
thought
about
and
always
worked
on,
is,
is
messaging.
How,
like
the
review
process
works
when
someone's
actually
like
taking
part
of
it,
because,
as
like
William
kalki
mention
is
talk
like
everything
is,
is
kind
of
scrutinized,
and
that's
just
so
that,
like
we
can
get
the
best
outcome
on
like
on
our
end
and
for
the
person's
end
who's
contributing.
C
We
want
like
their
contribution
to
be
like
as
good
as
it
can
be
and
make
everything
like
still
work
together.
Make
sure,
like
all
the
tests
are
passing
and
like
that
sort
of
thing
too,
and
just
like
messaging,
that
that's
all
part
of
the
process
and
its
regular
in
this
in
this
kind
of
contribution
model,
and
that
all
of
us
go
through
is
like
really
important
thing.
We
need
to
keep
up
yeah.
B
B
D
On
the
subject
of
like
retention
of
contributors
and
like
yeah,
there's,
there's
definitely
been
a
lot
of
cases
for
people
basically
doing
I
want
to
see
drive-by
commits,
but
like
throwing
one
committing,
and
that's
the
only
contribution
they've
made
I
think
what
what
had
me
contributing
more
over
time,
and
not
just
you
know,
dropping
the
one
thing
and
leaving
was
that
I
needed
to
get
things
done
right,
like
certain
things.
It
was
like
well
this
this
this
PR
needs
to
happen,
or
else
like
I
unblocked
at
work
right.
D
So
maybe
that's
something
that
we
can
try
and
emphasize
in
code
and
learning
and
notes
of
you
and
stuff
like
that
is
that
this
directly
affects
our
work
all
the
time
right
and
as
long
as
we're
seeing
it
not
is.
This
is
a
product
that
I'm
consuming
and
more
as
this
is
a
this
is
a
software
project
that
is
just
as
smart
as
much
a
part
of
my
code
base.
As
my
application
right.
H
C
I
just
want
to
know
that,
like
we
still
understand,
though,
that
people
don't
always
necessarily
have
like
time
for
that
or
interest
for
that,
like
even
if
you
just
make
one
contribution
like
we
still
really
valuable
out
value,
that
on
would
love
you.
If
you,
if
you
made
like
more,
we
would
love
that
on,
but
even
just
once
is
great.
Every.
B
One
thing
I
really
like
about
the
project:
is
it
doesn't
matter
how
small
the
contribution
is?
Your
name
gets
added
to
the
authors
of
this.
Just
like
everyone
else,
who's
who's
contributed
any
number
right.
You
know
it
doesn't
matter
how
smaller
smaller
contribution
is.
There's
equal
value
in
equal
importance
and
then
that's
when
they
got
the
real
life.
I
just
wanted
to
we've
got
about
23
minutes
and
I
have
a
couple
more
questions.
B
F
Retention
and
as
far
as
what
we
can
do
over
what
what
cork
and
you
wouldn't
know
to
do,
coming
up,
I
kind
of
had
a
whole
talk
about
it,
like
document
more
and
like
I,
didn't
really
get
a
chance
to
say
in
that
talk,
but
I
don't
have
I.
Don't
have
this
opinion
that
the
people
writing
code
need
to
be
the
ones
documenting.
I
I
want
to
open
up
avenues,
and
this
is
another
discussion.
F
We've
had
about
bringing
people
into
working
groups
as
like,
it's
a
terrible
name,
but
how
about
a
note
taker
or
something
like
that
or
whatever
so
because
getting
up
to
speed
on
what?
What
is
going
on
is
a
little
difficult,
sometimes
and
a
lot
of
people
don't
like
taking
notes
so
right
so
like.
If
you
want
to
help
out
it.
Just
maybe
you
don't
understand,
ansible
play
books
or
something,
and
you
want
to
get
involved
with
the
build
group
like
just
ghost.
F
B
B
F
Knowed
everywhere
is
that
high-level
enough
yeah
yeah,
so
the
work
that's
happening
with
the
bean
vm
neutral
is
a
pretty
high
level
thing
and
the
topic
of
a
small
core.
These
all
fall
into
no
being
available
on
different
devices.
You
some
devices
want
to
have
different
memory
management
and
swapping
out
the
vm.
To
just
you
know.
Maybe
chakra
is
is
better
on
large
memory,
applications
or
small
memory,
one
of
the
other
you're
able
to
swap
the
vm
out
in
and
your
device
is
better
using
that,
but
it
works
exactly
the
same.
E
Okay,
yes,
so
taking
note
everywhere,
a
little
more
literally
I
think
it
would
be
great
for
notecard
to
like
to
have
more
interaction
with
communities
that
are
not
mostly
bay
area-based.
I
mean
yeah
like
there's
a
lot
of
people
using
note
and
around
the
world
and
like
on
the
core
apposite
ori.
There
is
like
pretty
/
seeable
group
of
people
who
actually
do
contribute
frequently
and
Frank.
For
example,
what
we
sometimes
see
like
on
the
notes:
motive,
noches
/
help
repository
or
on
the
NPM
issued
cracker.
E
H
B
Was
recently
in
Tokyo
for
node
fest
Tokyo,
which
is
fantastic.
My
first
time
in
took
is
fantastic
City
and
that
same
way,
that's
the
same
idea
was
expressed.
Their
to
me
is
that
this
community
wants
to
be
closer,
involve
more
involved
with
what's
happening
with
core,
but
they
just
feel
completely
disconnected.
So
it's
a
very
good
point.
B
E
D
Right
level
bring
us
be
more
that
I
guess
kind
of
echo.
What
William
was
saying:
there's
a
lot
of
these
sort
of
bigger
projects,
longer-term
projects,
things
like
the
diagnostic
stuff.
Like
no
report
ll
know
things
like
that,
it'd
be
great
to
see
a
lot
of
that
being
brought
to
the
forefront
in
documentation
and
messaging
and
stuff,
especially
once
those
things
come
to
fruition,
as
well
as
the
bigger
things
like
chakra
core
and
heard.
C
German
I
think
there's
like
two
overarching
things
for
me.
I
think
like
improving,
like
the
clarity
and
visibility
of
of
how
our
processes
are
run
and
discussions
is
like
really
important
for
getting
new
people
and
and
keeping
those
those
people
involved
so
that
everyone
can
kind
of
have
a
perspective
of
what's
actually
happening
on
this
thing
that
they're
using
and
we're
contributing
to
in
whatever
way
they
interact
with
it
and
then
on,
like
a
technical
level.
F
So
if
you
speak
other
languages,
you
know
this
is
this
is
an
english-speaking
panel
up
here
so
but
like
I
really
wish.
We
could
take
this
away
from
being
like
thought
of,
is
just
like
an
english-speaking
community
because,
like
they
need,
they
deserve
so
much
props
for
all
the
work
they're
contributing
over
there
and
they
don't
get
enough
spotlight.
So
I
I.
B
Consider
myself,
bi
lingo
I
speak
fluent
nonsense
most
of
the
time.
So
let's
go
ahead
and
go
to
the
queue
I
think
I
can
barely
see
his
looks
like
so
good,
hey
games,
thanks.
H
It's
am
so
my
questions
about
url
url,
like
these
speaking
of
the
small
core
and
I'm
very
much
a
proponent
of
a
smaller
core
I'm
sensitive
to
the
eight,
not
wanting
to
break
the
world
by
taking
stuff
away,
but
there's
too
much
stuff
in
it.
So
where's
that
going.
What
are
we
going
to
do
with
the
conflict
between
the
the
current
URL
and
the?
What
working
group
Nouveau
spec
for
URLs?
And
you
know
one
or
two,
how
many
URLs
implementations
are
we
going
to
have
in
corner
I.
B
There
are
there
are,
you
know
there
are
a
number
of
issues
with
URL
parse.
If
you
look
at
the
w
what
WG,
I
you're
a
working
group
they've
basically
created
this
new,
sparse
respect
that
was
based
on
what
the
browsers
are
doing
and
they
created
along
with
that
a
test
suites
of
a
bunch
of
different
variations
of
URLs
that
can
be
parsed
URL.
The
URL
parse
in
node
fails
about
right
around
350
of
those
tests
and
they're
non-trivial
types
of
failures.
B
B
So,
as
I
was
looking
at,
this
I
was
looking
at
possibly
rewrite
the
internals
of
Europe
arson,
but
it
ended
up
being
just
easier
to
implement
the
what
WG,
URL,
spec
and
I
introduced
this
new
URL
object
into
core,
but
now
there's
two
URL
parsers
euro
person,
new
URL
and
right
now
it's
in
there
as
an
experimental
feature,
and
it's
in
there
is
experimental
for
the
very
deliberate
reason
that
we're
not
quite
sure
what
to
do
with
URL
parse.
Yet
right,
node
uses
URL
par
significantly.
B
Our
users
use
it
and
we
can't
just
make
a
clean
break
over
to
that
without
breaking
everybody,
and
until
we
get
that
story
figured
out,
we
can't
just
switch
over.
But
you
know
it
does
add
a
new
feature
and
it's
a
redundant
feature.
It
passes
all
the
tests,
which
is
great
its
you
know.
You
know
it's
there,
but
I'm.
Not
quite
I.
Don't
quite
have
an
adequate
answer
to
the
question
yet
because
we
still
need
to
figure
out
what
we're
doing
with
the
oral
parse
before
we
can
really
answer
a
question.
C
Yeah
I
think
in
that
case,
especially
it's
important
to
keep
in
mind
that
the
URL
spec
when
didn't
even
exist
when
the
original
URL
parser
was
implemented
in
core.
There
was
just
a
sort
of
rough
like
a
rough
idea
of
guidelines
around
it,
but
we
there
was
no
like
authoritative
source,
so
so
now
that
there
is
it's
like
a
little
bit
hard
to
to
bring
in
alignment
with
that,
I
think
like
either
way
like
no
matter
what
we
do
to
prevent
like
ecosystem
breakage
would
also
like
to
bring
stuff
more
in
line
with
compatibility.
B
G
Hi
this
question
is
a
very
simple
general
one
I
know
you
guys
O'brien
and
William
I
believe
you
got
started
contributing
by
having
an
issue,
essentially
that
you
were
trying
to
fix
and
that's
how
you
started.
But
do
you
guys
find
that's
how
most
people
get
starting
in
contributing
and
contributing
or
is
there
other
ways
you
know
before
I
get
started.
D
E
Let's
example
happen
what
happened
for
me
and
so
like
if
you
want
to
continue
I
contributing
to
a
node
car.
Great
things
to
do
like
if
you
have
the
time
is
watching
the
repository
again,
it's
a
lot
of
messages
that
it
helps
and
are
using
the
notes,
master
branch
locally
on
your
own
machine
just
for
everything
you
do
with
node,
because,
like
obviously
there's
some
bucks
gonna
slip
in
there
and
yeah.
C
Yeah
I
think
I
think
most
people
have
have
the
same
source
that
where
they
fix
it,
want
to
fix
a
problem
or
want
to
improve
something
in
some
way.
I.
What
kind
of
berries
and
more,
I
think,
is
what
comes
after
that
there's
a
lot
of
people
that
then
start
lending
more
commits.
There's
people
that
start
doing
more
documentation,
there's
like
all
range
of
things,
and
we
need
to
be
like
I
think
on
us-
is
to
keep
keep
looking
at
all
the
different
ways
that
people
contribute
to
bring
people
in,
and
we.
B
Gotta
we
have
an
interesting
mix
and
among
the
core
contributors
of
individuals
who
are
just
contributing,
you
know
by
themselves
and
those
of
us
who
are
paid
full
time
to
work.
On
my
the
reason
I
started
working
on
node
is
you
know
my
boss
at
IBM
said:
hey
James,
go
work
on
note,
so
ok
we're
going
to
do
that.
Yeah.
F
I
actually,
first
got
into
node
back
in
2010
so
very
long
time
ago,
and
that
was
well
I
should
say:
I
tried
to
commit
a
something
to
node
way
back
then,
and
that
was
because
a
feature
was
missing
and
it
wasn't
a
bug.
It
wasn't
a
problem.
I
guess
something
not
there
is
a
problem,
maybe
I
know.
However,
you
want
to
look
at
that,
and
but
it
wasn't
until
this
year
that
with
the
new
foundation
and
the
way
things
were
structured,
that
I
was
able
to
come
in
and
get
involved
so
I.
F
But
I
do
think
most
people
find
a
bug
find
a
problem
and
then
that
brings
them
to
the
repose
and
trying
to
figure
out.
Like
has
anyone
else
seen
this
they're
done
this
I'm
going
to
open
an
issue
and
maybe
they
get
engaged,
but
there
are
a
lot
of
people
that
we
consider
contributors
that
aren't
there.
They
they're
helping
out
with
events
like
this
or
just
helping
out
with
the
events
in
the
community
and
things
like
that
and
they're,
not
really
active
on
github,
so
we're
trying
to
open
up
the
mindset
of
you
know.
A
All
right
so
William,
you
mentioned
that
you
found
the
code
online
repository
and
it
was
just
dead
if
someone
were
to
find
another
repository
that
they
wanted,
they
were
interested
in,
but
it
was
dead.
How
would
you
approach
kind
of
any
of
you?
How
do
you
approach
making
it
start
going
again?
Oh.
F
Some,
my
approach
to
anything
that
I,
don't
understand,
is
to
die
just
kind
of
spit
out
the
info
that
I
was
able
to
find
because
the
more
info
that
you
can
show
that
you've
done
your
homework
done
your
research.
It
signals
like
you
really
put
effort
in
I
mean
if
you
just
open
an
issue
that
was
like
WTF,
you
know
like
people,
just
it's
gonna
go
in
the
trash,
but
you
know
I
have.
F
I
have
many
issues
I
open
and
I'm,
like
I,
saw
in
this
video
and
I,
linked
it
right
to
YouTube
to
that
time
in
the
video
where
James
snell
is
talking
about
this,
whatever
happened
with
that,
you
know
that
is
in
depth,
homework
right
and
it
means
I'm
serious.
I
want
to
really
know,
and
I
really
believe
that
this
should
happen
and
I'm
willing
to
put
all
this
time
from
myself
into
this,
and
could
somebody
else.
Please
help
me
the
more
you
show
interest
the
more
somebody
feels
like
you.
B
Yeah,
there
was
a
lot
of
things
when,
when
first
letter
getting
involved,
you
know
the
TSU.
We
would
have
a
lot
of
discussions
and
a
lot
of
things
we're
going
undone
and
it
was
because
you
know
that
we
didn't
have
time
or
we
just
you
know
we
just
didn't
get
to
it
or
didn't
think
about.
You
know
we
assumed
somebody
was
doing
it
like
uploading.
The
minutes
to
you
know
online
and
I
I
really
appreciate
the
contribution
of
ways
make
I
mean
you
haven't,
contributed
any
code
decor
but
I.
B
B
There's
there's
many
ways
that
that
people
can
contribute
so
any
other
I
can't
I
cannot
see
to
the
queue.
So
if
anyone
else
out
there
nope
okay,
so
we
have
like
six
minutes.
I'll
do
my
final
question:
unless
there's
anyone
else,
that's
cute,
okay,
so
personal
priorities,
personal
threads,
you
want
to
pull
a
node
over
the
next
year
or
so
oh
yeah.
F
That
was
easy
for
me.
I'll
say
it
a
different
way,
though.
F
What
is
what
is
the
right
way
to
do
this,
and
how
are
we
telling
people
we're
doing
this
versus
how
we're
really
doing
this
and
so
documentation?
So
for
me,
it's
all
about
putting
it
down
and
I
would
the
first
year
we
were
all
scattered
and
did
all
those
different
directions,
but
I
would
like
to
keep
that
going,
bring
more
people
in
to
help
solidify
and
like
Whittle
things
down.
F
I
recently
started
a
thing
of
removing
one
of
the
working
groups,
the
roadmap
working
group
that
it
wasn't
doing
anything
and
the
core
team
was
basically
doing
it
anyway.
So
and
nobody
objected
to
it.
So
you
know
just
little
by
little
taking
this
back
in,
so
it's
very
digestible
for
new
people
to
come
on
and
that's
definitely
my
high
priority
know
that.
E
Appreciate
it
no
I
guess
for
me,
it's
like
what
I've
basically
already
touched.
We
have
a
lot
of
users
that
don't
regularly
interact
with
note
car
and,
for
example,
when
I
first
started
contributing
to
an
old
car.
I
was
really
surprised
by
how
much
of
the
disconnect
the
west
between
like
note
core
and
the
people
who
are
active
on
that
and
the
rest
of
the
ecosystem
that
I
have
had
interactive
with,
which
is
obviously
only
part
of
it.
B
D
So
I
think
what
I
would
like
is
to
you
know,
be
involved
with
myself
and
see
a
lot
more
of
in
the
coming
year
or
so
on
is
a
lot
more
of
the
effort
we
had
started
with
the
documentation
working
group
which
was
making
guides.
So
there
was
this
effort
to
have
a
series
of
guides
like
how
do
I
actually
use
this
API
rather
than
just
having
the
terse
API
Docs,
and
that's
an
effort
that
I
think
I
want
to
I
want
to
see
that
grow
a
lot
more
this
year.
C
One
of
the
things
I've
been
helping
helping
out
with
and
then
I'm
going
to
be
continuing,
I
think
quite
a
bit
doing
the
next
year
is
we
have
a
hub
bought
that
does
a
bunch
of
automation,
stuff
they're
really
helps
out
and
bring
visibility
to
what
a
test
statuses
from
our
continuous
integration
suite
across
like
multiple
platforms,
and
it
also
does
some
other
things.
It
automatically
things,
tags
issues,
pull
requests,
so
I
think
improving.
C
That
will
help
like
the
developer,
experience
a
lot
for
people
contributing
to
node
core
and
help
smooth
things
out,
and
then
also
I've
already
been
in
this
and
the
weeds
in
this
a
little
bit.
But
we
kind
of
need
to
do
something
about
es
modules
and
so
I'm,
probably
gonna,
be
continuing
to
help
lead
that
direction.