►
From YouTube: Node.js User Feedback Initiative Meeting
Description
B
B
Then,
what
a
team
of
50
and
a
team
of
100
have
to
maintain
every
single
day,
whether
it's
a
monolithic
approach
to
building
software
and
node,
or
if
it's
the
crazy
world
of
micro
services
and
hundreds
and
not
thousands
of
individual
small
applications,
so
we're
looking
for
surfacing
those
lessons
and
those
challenges,
perhaps
to
note
itself
we're
not
in
the
realm
of
talking
about
frameworks
or
technology
or
solutions
around
node
itself,
and
the
reason
for
that
is
we
want
to
take
any
feedback.
You
have
any
experiences,
you
have
any
particular
challenges.
B
You
have
around
node
itself
back
to
the
technical
groups
and
the
groups
working
on
node
itself
to
then
further
improve
it.
So
if
you
have
any
conversations
about
frameworks
or
libraries
or
things
like
that,
those
are
definitely
valuable
and
fun,
but
I
don't
think
we
are
able
to
do
much
with
that
in
this
form.
So
with
that
my
name
is
Ahmed
Nazari.
A
Then
fell
I'm
the
champion
for
the
node
user
feedback
initiative
that
this
rolls
up
to
a
member
of
the
community
community
and
general
sort
of
know.
Jess
oh
gee
and
I'm
joined
today
by
my
kids.
I
got
Matthew
and
Jasmine,
it's
kids,
a
birthday
or
PayPal,
and
so
I
forced
my
kids
to
come
and
participate
with
this
meeting
as
a
general
indication
of
what
I
do
with
my
life.
C
B
D
E
B
Perhaps
just
as
a
quick
data
point,
and
we
can
go
back
to
quick
numbers
like
how
big
are
the
teams
that
do
touch
or
work
on
node
and
your
company
and
how
many
software
distributions
or
packages
or
applications
you
know
rough
part,
roughly
I'll
start
like
the
at
TELUS.
We
had
a
team
of
five
hundred
people
and
about
two-thirds
of
that
were
software
engineers
and
we
had
over
1,700
individual
software
applications
about
900
of
those
were
in
node
or
using
nodejs.
A
F
I'll
just
do
this
real,
quick
thanks
for
the
moment
so
yeah,
hey,
Aaron,
I'm,
Aaron's,
Heckman
and
here
over
at
PayPal
I,
work,
Dan
and
so
I'm
on
a
team
that
maintains,
you
know,
frameworks
and
build
tooling
infrastructure
for
nodejs.
You
know
Web
Apps
at
PayPal
and
that's
all
I'm
gonna
say
about
myself
today:
I
can't
stay
long
today,
but
I
have
been
invited
to
meet
so
you'll,
see
him
in
here
too,
and
I
invited
him
because
he's
had
a
lot
of
experience.
F
Working
on
some
of
the
session,
the
TLS
session
management
we've
had
with
the
nodejs
recently
and
he's
been
making
a
lot
of
progress
there.
So
I
really
wanted
him
to
chime
in
here
later
on.
When
we
get
to
that
part.
So
you
know,
please
give
him
a
welcome
as
well
he's
on
my
team
and
I'll.
Let
him
speak
for
himself
from
this
point
forward,
but
that's
it.
That's
all
I
want
to
say
I'm
I
get
out
of
the
way
so.
D
G
D
B
E
Microsoft
has
a
hundred
and
thirty-one
thousand
employees,
and
I
really
have
could
not
say
like
what
kind
of
numbers
we
have.
Obviously,
our
node
numbers
are
much
smaller.
Most
of
our
stuff
is
in
dotnet,
but
we
do
have
some
pretty
major
architecture.
I
think
our
biggest
one
would
be
app
insights,
which
is
our
telemetry
platform.
E
H
I
J
Sure
I'm,
a
VM
skini
lead
for
nodejs,
chair
of
the
technical
steering
committee
member
of
the
community
committee
and
active
enthusiasts
for
the
user
feedback
group
as
well
in
terms
of
number
of
Ibn
people
working
on
node
again,
I.
Don't
have
a
good
answer
to
that.
There's.
So
many
different
groups
spread
across
all
the
projects,
but
there's
a
fairly
good
number
as
well.
K
K
Anyway,
no
I
support
a
lot
of
most
of
my
stuff
is
actually
on
a
different
level,
so
basically
I'm
on
an
evangelist
for
the
nodejs
stuff
at
the
enterprise
level,
so
I'm
a
big
container
freak
and
we're
working
a
lot
of
customers
and
clients
that
actually
use
node.
So
my
perspective
is
actually
for
our
China,
the
broader
perspective
of
what
enterprise
people
want
a
lot
of
its
deployment
scale
out
and
security
type
things.
Those
are
the
probably
two
big
issues
on
you.
H
B
Cool,
thank
you
so
the
reason
I'm
interested
in
numbers,
because
they
do
help
set
the
context
of
the
type
of
conversation
we're
about
to
have
right
so
I
did
create
a
bunch
of
like
topic
topics
to
go
over.
We
don't
have
to
stick
to
them
in
particular,
but
those
are
the
general
themes
that
we're
looking
to
surface
out
of
your
experiences
and
take
those
lessons
back
to
the
node
project
and
I'm
actually
going
to
start
a
little
bit
backwards.
Given
that
version
12
was
just
released,
hopefully
you're
all
aware
of
it.
B
The
question
that
comes
out
of
that
you
know
everybody
gets
interested
in
the
features.
Everybody
gets
interested
in
new
delivery
of
functionality
that
they're
looking
for,
but
a
pattern.
I've
notice
in
large
teams,
especially
the
the
legacy
applications,
don't
always
get
attention.
So
I
know
this
for
again
from
the
Telus
experiences.
You
know
how
many
people
who
are
still
running
applications
on
v6
and
then
knowing
that
v6
is
gonna
end
of
life
in
about
two
weeks
or
a
little
bit
less.
Even
there's
risk
in
that.
B
I
struggled
and
having
a
cadence
even
of
having
a
visibility
into
that
schedule
as
part
of
the
daily
operations
of
the
teams
and
the
road
mapping
work
of
the
team,
so
I'm
interesting
to
hearing,
if
you
or
your
companies,
have
any
interest
or
have
surfaced
any
patterns
in
terms
of
keeping
up
to
date,
with
not
just
security,
patches
and
releases.
But
you
know
something
as
basic
as
the
end-of-life
sky
to
all
four
four
older
versions
of
Mount
Oh.
G
You
know
the
built-in
ones
in
NPM,
we'll
see
some
other
third-party
ones
as
well,
but
then
also,
you
know
just
keeping
on
top
of
twitter
or
keeping
on
top
of
email
distribution
groups.
So
there
isn't
a
sort
of
a
single
unified
way
of
getting
all
of
that
information.
It's
there,
the
network
that
you
are
required
to
build
up
in
order
to
ensure
that
you're
at
Europe
today,
with
your
all
your
various
different
dependencies,
see.
B
That
that's
interesting
to
me,
because
the
the
information
has
always
been
there,
for
example
in
terms
of
release,
schedule
right
and
I,
because
I'm
personally
interested
I
check
on
it
every
once
in
a
while,
but
I
still
fail
to
have
a
mechanism
of
rolling
that
into
the
the
planned
work
and
the
budgets
and
the
tracking
and
all
that
stuff
right.
So
I,
don't
know,
I,
don't
know
if
Microsoft
does
something
different,
assuming
they're
a
bigger
organization,
they've
been
doing
more
detailed
software
level.
Experience
I,
don't
know
if
Netflix
has
an
idea
of
that.
B
But
ultimately,
is
there
anything
that
the
node
project
can
do
different
in
terms
of
not
just
announcing
something
and
posting
it
on
Twitter,
but
in
giving
you
that
roadmap
and
it
may
be
a
different
file
structure
or
different
visibility
that
help
you
take
that
back
to
your
teams
and
actually
roll
that
part
of
your
planning
and
part
of
your
work
because
sure
it's
on
a
github
repo
somewhere.
But
if
you
don't
look
at
it
and
if
you
don't
use
it,
then
it's
not
really
doing
you
any
good.
The.
J
B
But
but
how
does
that
roll
into
the
work
right
like
I,
like
Luke,
you
mentioned
you're
like
an
advocate
internally
and
externally,
but
do
you
have
an
uphill
battle,
trying
to
schedule
upgrade
work
or
actually
trying
to
convince
product
teams
to
do
any
sort
of
upgrades
on
things?
Do
you
have
to
assign
budget
to
it
like?
What
is
what
is
a
typical
process?
Look
like
for
a
team
of
your
size,
so.
G
It
generally
it's
based
on
on
either
push
or
pull
so
the
core
would
be
if
we
we
need
features
that
are
only
available
in
the
newer
runtime
versions
and
and
push
would
be
if
it's,
if
it's
a
security
related
patch
that
we
have
to
patch
for
so
in
terms
of
building
those
into
the
cycle.
What
we
do
is
we
build
a
little
contingency
into
into
our
normal
esperan
planning
and
just
accept
the
fact
that
there's
going
to
be
updates
not
just
from
node
but
from
a
whole
range
of
other
tools
that
we
use.
K
K
So
if
the
releases
fall
two
or
three
behind
and
within
their
cadence,
which
might
be
six
months
or
three
months
or
even
a
year
in
some
cases
that
becomes
an
issue
right
because
then
you
get
out
of
whack,
you
get
out
of
sync
and
then,
as
was
just
said,
there's
a
secondary
cadence
that
occurs.
It's
not
kate
exception
that
occurs
obviously
for
security
risks,
so
yeah,
so
security
patches,
actually
trump
all
the
other
stuff.
But
but
for
the
most
part
my
clients
are
very,
very
strict.
Cadence
I
would
like
tossing
different
matter.
J
Just
gonna
ask
a
question
on
this:
since
you
mentioned
the
security
releases,
there's
always
going
to
be
like
ad-hoc,
high
security
releases
for
things
like
you
know,
open
SSL
has
boner
abilities
or
whatever
we
are
discussing
internally,
whether
something
like
a
regular
schedule
for
lower
lower
lower
vulnerability
security
releases
would
make
sense
so
I'd
be
interested
in
this
groups.
Input
on
that
in
terms
of
you
know,
if
we,
if
we
plan
to
do
those
every
every
say
four
months
say
and
roll
things
up
in
to
them.
So
basically
some
things
may
come
out
later.
K
That's
a
good
question,
so
I
for
my
perspective
that
it's
probably
better
rolled
up
in
no
kaidan
see
if
it'll
s
their
severe.
Obviously
this
Trump's
everything
but
I
mean
TLS
stuff
over
going
over
time,
everybody's
planning
stuff.
So
they
just
go
okay.
You
know
we
gotta
go
bigger,
keys
and
stuff,
so
it's
kind
of
go
and
that
can
be
cased,
so
I
think
roll
em
up
is
a
good
idea.
I
do.
G
But
I
think
you
know
it's
again:
it's
the
case.
We
have
to
do
on
a
case-by-case
basis.
You
may
be
using
node
in
an
awful
way,
and
so
therefore
you
may
find
out
something
that's
low.
The
risk
to
most
users
might
be
higher
risk
for
the
way
that
you're
using
it,
and
so
it's
important
to
sort
of
to
take
all
security
patches
and
do
the
risk
analysis
on
those
as
per
your
requirements.
One.
B
Of
the
challenges,
I've
noticed
and
again,
I
don't
want
to
talk
about
packages
themselves
and
this
conversation,
but
sometimes
you're
stuck
and
not
able
to
upgrade
a
virgin
or
get
even
a
security
patch,
because
the
dependencies
your
your
lying
on
might
be
somehow
tied
back
to
that
yeah.
That's
that's
an
interesting
challenge.
Yeah.
K
I
Yeah
Linda,
one
of
the
challenges
we
are
facing
at
PayPal
is
that
you
know
one
of
the
recent
security
fixes
reduced
the
header
length
and
you
know
a
lot
of
our
internal
teams.
Were
you
know,
depending
on
a
high
order,
the
header
length,
and
you
know,
certainly
for
them
it
went
down
to
8k.
So
you
know
stuff
like
that,
could
be
challenging.
You
know,
could
slow
us
down
releasing
some
of
the
security
vulnerability
fixes.
So
it
is
similar.
D
I
I
mean
that's
what
we
are
doing
to
you
right
now.
The
thing
is
that
it's
still
slows
down,
because
you
know
you
have
to
push
it
out.
You
know
it's
not
as
trivial
as
you
know,
letting
other
teams
team
just
pick
the
latest
right.
You
know
we
have
to
include
that.
You
know
additional
flag
in
order
in
the
infrastructure
itself.
G
Another
constraint
is
in
terms
of
just
fatigue
on
on
the
engineers
for
changes
and
changes
to
way
of
working
with
with
different
versions
of
node,
and
that
is
largely
dictated
to
us
by
some
of
the
cloud
vendors
that
we
use
in
the
supported
versions
of
the
versions
of
note
that,
where
you
have
available
through
those
for
the
on-premise
tour
a
bit
more
freedom.
Obviously
we
can
roll
our
own
images
and
put
them
up
into
in
declared
vendors.
But
for
the
most
part
we
tend
to
stay
with
the
main,
supported
versions,
just
because
they're
handling.
G
B
So
using
that
context
of
you
know,
engineering
fatigue
and
also
things
are
happening
now,
like
with
version
6
being
end-of-life
in
a
couple
weeks.
I'm
also
gonna
use
the
opportunity
to
introduce
Steve
and
maybe
throw
him
under
the
bus,
stiva
think
from
Telus
joining
us
and
I
know
for
a
fact,
there's
a
lot
of
no
js'
six
dependencies
or
deployments
out
there
in
production.
L
Today,
there,
the
I
just
came
out
to
a
meeting.
Where
is
now
a
bad
scramble
where
yeah
people
are
suddenly
realizing,
they
have
a
whole
bunch
of
stuff,
but
so
it's
the
interesting
thing
is
for
us
is
that
well
I
think
there
was
about
25
packages
or
a
group
that
we
have
identified
still
running
node
6
and
it's
like
20
of
them
can
just
get
banned
and
killed
like
which
is
one
of
those
things
like
the
fact.
L
It's
like
work
that
we're
actively
working
on
being
mostly
maintained,
and
we
have
the
sort
of
you
know
the
the
endless
drift
of
unloved
code
kicking
around
still
that
no
one's
ever
actively
shut
down,
but
I
have
no
propose
to
our
leadership
that
does
get
tied
like
too.
Our
leaders
performance,
which
you
know
I,
got
a
whole
bunch
of
complaints
about
that.
But
it's
because,
like
everyone's
driven
by
the
I,
have
to
you
know,
deliver
business
calm.
It's
really
like.
That's
the
only
other
believer
that
we
can
really
push.
B
So
so
that's
an
interesting
segue
as
well
to
another
topic.
I
want
to
talk
about
so,
but
before
we
do,
that,
I
would
ask
perhaps
for
those
who
have
not
looked
at
the
node
releases,
repo
I
believe
it's
called.
If
you
go
to
get
up
a
calm,
/
mogea,
slash,
releases,
I,
believe
that's
the
URL
of
my
mother's.
F
J
B
Will
also
link
it
in
the
github
issue
and
hopefully
I'll
send
an
email
followup
with
some
links.
They're
useful
links,
but
I
would
I
would
suggest
anybody
who
hasn't
looked
at
it
like
to
take
a
look.
I
know,
I've
mentioned
that
you
look.
You
mentioned
you
looked
at
like
tweets
and
and
newsletters
and
those
kind
of
things.
B
It
would
be
useful
to
look
at
that
repo
and
provide
any
feedback
if,
if
in,
if
it's
in
current
format
is
something
you
can
take
as
Steve
was
saying
leadership
teams
and
make
sure
that
those
work
plans
are
our
months
ahead
that
are
coming
down
anyways
or
at
least
taking
that
into
consideration
and
then
provide
the
feedback
to
this
group
of
saying.
Well,
this
is
what
works
and
this
what
doesn't
and
to
take
on.
B
So
maybe
that's
the
homework
for
one
item
and
then
to
take
on
the
note
that
Steve
were
referencing
in
terms
of
you
know
the
the
cost
of
adoption
or
the
total
cost
of
ownership.
This
is
something
I've
also
struggled
with
in
trying
to
surface
a
good
kind
of
measure
or
a
good
answer.
So
we
know
we
have
all
these
micro
services.
We
have
all
these
middlewares
and
ApS
and
web
applications
have
any
of
your
organization's
or
your
development
teams
been
able
to
articulate
in
one
shape
or
form.
B
There's
lessons
there
for
the
node
project
to
take
away
and
other
incorporate
that
as
part
of
documentation
as
part
of
training
materials
as
part
of
knowledge
management
solutions
that
the
node
foundations
can
invest
more
and
or
just
create
if
they
don't
exist,
to
help
organizations
such
as
yourselves
with
that
total
cost
of
ownership
challenge,
because,
in
my
view,
I
would
imagine
that
starts
from
hiring
all
the
way
to
maintaining
and
production.
So
and
there's.
J
Thing
I
one
dad
to
is
I'd
also
be
interested
like
the
specific
thing
that
was
mentioned,
that
even
like
turning
the
flag
on
requires
rolling
things
out,
so
any
feedback
on
you
know
small
changes
that
might
help
make
that
easier.
So,
for
example,
if
you
actually,
you
know,
take
the
the
binaries
vet
them
and
could
like
add
a
default
configuration
file,
if
that
would
make
that
significantly
more
easier,
that's
something
that
would
be
worth
exploring
like
you
know.
J
M
K
I
It's
a
it's
a
great
point.
You
know
you
know
rolling
a
flag
out.
You
know
which
means
that
when
the
node
is
launched
wherever
it
is
launching
it
have
to
make
sure
that
particular
flag
is
passed
in
versus
configuration
which
is
easier
to
deploy.
Config
file,
which
is
easier
to
deploy.
Yeah
I
mean
I'm
very,
very.
J
Calm,
you
know
something
that
popped
into
my
head:
I,
don't
know
if
it's
been
discussed
in
the
past
or
whatever,
but
those
kind
of
suggestions
are
feedback
from
the
actual
in
use.
Problems
are
great
things
for
us
to
get
back,
because
you
know
we
we
said
well.
We
want
to
make
sure
that
when
we
make
this
change,
there's
an
easy
way
to
fall
back,
but
if
there's
still
friction
with
that,
you
know
you
I'm
sure,
we'll
be
open
to
to
other
things
that
will
hopefully
reduce
that
even
further
I.
B
Guess
an
abstract
way
of
reacting
that
question
to
use
that
example
Michael,
provided
is
you
know
where
do
you
spend
most
of
your
teams
of
time
and
effort
if
it's
I,
even
using
binaries
or
using
docker
containers,
and
therefore
all
your
flag
management
happens
in
a
darker
layer
right
and
maybe
maybe
that
knowing
that,
even
though
we're
not
gonna
touch
docker
itself,
maybe
there's
something
there
for
the
node?
Could
the
node
core
itself
to
make
better
towards
that?
But,
like
that's
what
I
mean
by
the
total
cost
of
ownership
like?
B
A
So
I
think
there's
one
thing.
You
know
for
folks
to
consider
here
that
you
know
there's
a
pretty
big
delineation
at
PayPal
between
the
infrastructure
teams
that
you
know,
focus
on
rolling
out
our
capabilities
and
the
application
teams
to
focus
on
building
the
applications
with
those
things.
Those
are
you
know,
separate,
separate
work,
totally
separate,
workflows
and
distinct
teams
that
are
managed
each
of
those
things.
So
it's
not.
A
You
know
in
the
same
pool
of
folks
everybody's
sort
of
going
back
and
forth
dealing
with
these
nodes,
as
things
know
or
like
we're
dealing
with
application
logic
and
how
that's
being
executed
and
and
oftentimes
the
constraints
of
you
know
what
we
can
support
as
a
platform.
For
example,
we
can't
run
ten
because
of
our
open,
SSL
constraints
there,
which
we
should
you
know
have
to
meet.
You
know
share
some
more
about
that,
but
you
know
so.
A
G
Coming
back
to
your
question,
the
original
question,
which
was
around:
how
do
you
quantify
the
total
cost
of
ownership
we
tend
to
be
tend
to?
We
tend
to
do
that
in
a
comparative
way
against
other
technologies
and
tools
for
which
we
have
experience
within
the
workforce,
and
quite
often
one
of
the
blessings
of
of
microservices
and
and
and
so
in
general.
Is
that
we're
able
to
kind
of
compartmentalize
functionality
based
on
those
strengths
of
skills,
but
in
terms
of
total
cost
of
ownership?
We
look
comparatively
at
other
tools.
G
We
look
at
the
tools
that,
where
we
have
knowledge
within
the
team
and
the
biggest
thing
that
I
can
sort
of
that
sticks
out
at
me
as
a
striking
difference
between
working
with
with
node
and
with
other
tools,
is
the
fact
that
node.
While
it's
got
this
plethora
of
libraries
that
are
fantastic
for
the
the
choices
of
standard
libraries
are
rich
and
varied,
and.
C
G
Having
a
way
of
tracking
what
we
as
a
enterprise
organization,
users,
are
standard,
node
libraries
and
is
something
that
we
have
to
do
outside
of
the
side
of
the
npm
ecosystem,
usually
ends
up
in
wikis
or
or
other
tools
and
the
review
process
around.
What
we
now
accept,
there's
a
library
that
we're
we're
favoring
within
the
organization
is,
is
more
manual
than
it
feels
like.
It
should
be.
G
So
from
that
perspective,
because
we
don't
have
a
very
rich
standard
standard
library,
that's
off
the
shelf,
and
we
have
to
sort
of
extend
that
ourselves
with
other
libraries.
The
there
is
a
sort
of
a
need
there
for
being
able
to
say
well
yeah.
These
are
the
features
are
built
in
a
node,
and
these
are
the
libraries
that
this
particular
enterprise
organization
uses
it
across
the
board.
And
so,
therefore,
you
can
get
them
from
the
private
NPM.
G
Repo
and
they're,
supported
and
they're
security,
checked
and
review
know
those
sorts
of
things
so
that
that
would
be
the
only
thing
where
I
can
say
that
there's
a
big,
significant
difference
in
the
amount
of
investment
that
you
have
to
put
in
it's
kind
of
like
a
hidden
cost,
but
it's
also
a
great
strength,
because
you
don't
have
to
contend
with
something.
That's
in
the
standard
library
you
don't
want
to.
Have
you
just
bring
in
what
you
need
so
anyway?
I
would.
B
Yeah,
that's
definitely
a
good
point,
especially
towards
the
end
where
it's
also
a
strength
I'll
be
curious
to
know
if
again
like
what
is
the
business
impact
of
that.
So
there
is
a
cost
of
felt
cost
as
well.
Well,
how
big
of
a
cost
is
it
for
each
of
your
organization's
having
to
deal
with
that
either
constantly
or
at
the
inception,
phase
of
a
project
or
projects
to
the
point
of
well?
B
How
can
we
collectively,
as
individual
contributors
and
the
note-for-note
foundation
itself,
actually
go
out
and
invest
in
doing
something
about
that
actually
may
be
building
a
standards
library,
if
that
is
the
direction
right,
I'm
not
saying
it
is,
but
how
do
we
measure
that?
How
do
we
are
able
to
effectively
say
you
know,
hypothetically
speaking,
you
know
sage
runs.
You
know,
infrastructure
that
opera
that
operates
hundreds
of
millions
of
dollars
worth
of
transactions
and
businesses
and
Microsoft
in
the
similar
boat
and
Netflix.
You
know
operates
all
of
our
entertainment.
B
So
therefore
it's
dead
flex
gonna
happen.
First,
because
you
know
I
need
to
watch
my
TV
shows
or
whatever
metric.
That
may
be
right
in
order
for
us
to
mobilize
action,
a
notice
for
us
to
as
part
of
individual
contributor.
You
know
volunteer
base.
We
can
prioritize
that
action,
so
that's
that's
I!
Think
one
of
those
gaps,
we're
looking
to
answer
I
think.
G
M
B
J
Think
that
we
to
the
efforts
of
the
package
maintenance
team,
where
you
know
the
effort
is
to
figure
out
how
we
bring
people
together
to
make
sure
that
the
key
modules
that
the
ecosystem
depends
on
are
in
a
good
state
and
that
the
first
challenge
is
always
like.
What
is
that
list
of
modules
you
can?
You
know
you
can
come
up
with
the
top
few,
but
then,
when
you
go
beyond
that,
we
needed
the
sort
of
regular
feedback
and
I
think
the
enterprise.
You
should
should
figure
into
that.
E
G
E
G
Nice
be
factual
in
terms
of
this.
Is
these
organizations
use
these
ones?
Currently,
this
is
not
a
saying
that
you
should
go
outside
of
that
shouldn't
go
outside
of
that
list,
and
you
can
imagine
that
some
managers
would
be
at
some
point
if
they
they
thought
it
was
some
kind
of
badge
of
quality.
They
would
probably
be
averse
to
having
libraries
from
outside
of
that
list
being
consumed
and
I
can
see
what
you're
you're
getting
out
there
Brian
in
terms
of
a
potential
threat
to
that
very
diverse,
beautiful
and
ecosystem
that
we
yeah
well.
B
D
B
Was
gonna,
say,
I
think,
there's
there's
gradients
to
that
level
of
conversation
right
like
we,
don't
have
to
go
all
the
way
to
you
know
and
enterprise
approval
the
list
of
magic
modules,
but
knowing
that
and
knowing
that
there
is,
for
example,
say
depends
on
a
number
of
key
packages
and
knowing
that
there
is
a
package
maintenance
initiative,
I
mean
I,
don't
know,
maybe
not
sure
how
I'm
gonna
say
show
of
hands,
but
not
everybody
has
the
camera
on.
But
does
everybody
know
about
the
package
maintenance
initiative?
B
That's
ongoing
right
now
and
if
you
don't,
you
should
check
it
out
and
the
link
is
in
the
issue
that
I
think
Michael
and
others
are
leading
where
the
focus
there
is
is.
How
do
we
make
sure
that
we
are
signaling
the
open
source
community
and
the
developers
who
run
or
maintain
those
individual
that
we
all
rely
on
signal
to
them
our
support
and
signal
to
them
methods
of
better
interacting
with
their?
B
You
know
millions
and
millions
of
dependents
and
perhaps
that's
like
a
kind
of
a
middle
tier
of
you
know
if
Microsoft
or
Netflix
or
sage
or
tell
us,
goes
out
and
some
systematic
way
and
says
well,
these
are
the
packages
we
care
about.
Then
you
either
can
then
go
and
contribute
to
them
more
clearly
by
making
that
business
case
more
clearer.
B
L
Yep
right
now
it
tell
us
I'm
bringing
on
a
whole
new
department
onto
node,
so
there
are
25
Java
developers
so
far.
Their
biggest
fear
is
that
they
don't
have
this
standard
approved
list
of
libraries
that
they
can
use
and
they're
worried
about,
be
chaos
and
how
they
can
ever
actually
personally
review
every
library
every
time
they
want
to
do
anything
I
think
it's
a
mystery
like
culture
shifter.
L
They
have
this
incredibly
regimented
world
they're
coming
from,
and
here
I'm
here
I'm
trying
to
convince
them
that,
like
the
glory
of
this,
is
the
sois
and
options
available
to
them
and
all
I'm
getting
in
response
so
far
is
like.
Oh,
my
god,
I'm
gonna
spend
all
my
time
just
sort
of
browsing,
endless
libraries
and
how
do
I
know,
which
ones
that
tell
us
approves.
Oh.
D
We've
been
learning
something
similar.
It
looks
and
like
a
quick
audit
of
one
of
our
code
base
that
showed
that,
like
the
node
modules,
the
directory
tree
at
about
1.7
million
lines
of
code
in
it,
which,
at
that
point,
you've
kind
of
reached
a
point
of
no
return
in
terms
of
trying
to
even
audit
the
amount
of
code
that
you've
deployed
and
we're
exploring
policy
based
and
formas,
or
enforcement
at
runtime,
where
you
define
what
acceptable
behavior
of
this
process
is,
as
opposed
to
exploring
like
trying
to
actually
find
a
way
to
system.
H
H
On
the
stuff
that
we
actually
deploy,
that's
besides
all
the
other
tooling,
but
just
the
top
level
services
that
we
do
deploy.
They
depend
on
around
2000,
unique
versions
and
in
a
week
the
drift
of
code,
basically
I
compared
two
sets
to
snapshots
of
the
whole
node
modules
across
I.
Don't
know
20,
repos
or
so,
and
that's
2,000,
unique
questions.
There
were
around
think
three
or
four
thousand
lines
of
changed
code
in
a
week,
we're
a
small
project,
I
suppose
in
a
certain
scale
right.
H
But
there
is
a
case
that
some
of
that
might
be
reviewable,
especially
after
you,
you
rule
out
certain
modules
where
you
don't
really
need
to
review,
because
there's
large
generated
files
on
that
kind
of
stuff.
So
once
you
filter
those
out,
there's
yeah
the
drift
that
that
that
I
was
looking
at
was
around
three
four
thousand
lines
of
code
weekly.
G
If
you
think
about
all
those
modules-
and
you
think
about
node
the
runtime
and
then
you
think
about
all
the
different
other
platforms
and
tools
that
we
use
around-
that
that
you're,
the
Dockers
and
all
these
other
things
they
all
have
release
Cadence's,
they
all
have
read,
means
that
we
need
to
go
and
check
out
and
Twitter
feeds
that
we
need
to
go
and
listen
to
and
our
approach.
That
is
actually
quite
ad
hoc.
G
So
my
question
is:
is
given
that
node
now
has
this
fantastic
link
into
that
to
the
the
Linux
Foundation
side
of
things,
and
is
there
a
way
that
we
can
sort
of
standardize
how
we
inform
businesses
about
what
versions
of
things
are
coming
out
when
in
a
standard
way?
So
the
well
not
not
without
solutionizing
the
things
that
pop
into
my
head
are.
Could
we
use
a
standard
calendar
format
or
could?
G
Is
there
a
standard
sort
of
feed
way
that
we
could
do
that,
so
that
we
can
have
that
information
literally
flying
into
our
project
management
tools
and
allowing
us
to
plan
for
the
things
that
we
need
to
do
over
the
next
few
weeks?
You
know
where
we
see
that
this
the
security
updates
coming
in
or
we
see
that
there's
a
normal
release
cycle
I,
don't
think
this
is
a
problem,
that's
isolated
to
note
and
that's
why
I'm
asking
if
this
is
sort
of
a
more
general
approach
to
it.
Well,.
B
I
was
gonna,
ask
that
exact
same
question,
but
in
a
completely
different
method,
I
was
gonna.
Ask
is
given
that
this
group
is
the
node
foundation
and
whatever
solution
we
can
but
propose
or
come
up
with
the
real
question
to
me
is:
will
your
business
use
that
like
do
does?
Does
your
company
look
at
the
node
foundation
as
a
source
of
truth
or
an
entity
that
they
want
to
get
answers
from,
or
do
they
treat
it?
As
you
know,
oh
there's
something
I'm
gonna
help
we
can
just
use.
B
If
there's
something
on
NPM
we
can
just
use
and
there's
no
thought
beyond
that
right
and
the
reason
I
ask
is
because
you'd
I,
like
that
idea
by
the
way,
like
a
standardized
calendar
format,
of
some
sort
that
you
can
plug
in
into
actual
roadmaps.
But
if,
if
the
businesses
don't
see
value
in
trusting
or
relying
on
an
entity
such
as
the
node
foundation,
then
you
know,
maybe
we
need
to
look
for
alternatives
or
different
methods,
but
I.
B
A
Been
you
know,
one
of
the
other
things
that
I
roll
into
that
I
think
all
bender
had
on.
Is
you
know?
Also,
do
you
look
your
vendors
right,
so
you
know
there's
there's
often
that,
especially
in
the
enterprise
situation,
you
know
looking
to
a
vendor
whose
job
it
is
to
look
at
no
Jazz
foundation
constantly
is
one
of
the
ways
that
you
can
solve.
That
relationship.
B
Is
slick
I
like
that
yeah
I
like
that
there's
something
about
the
van
context.
That's
not
exactly
what
you're
saying
but
yeah
you
know.
Steve
can
speak
more
to
that
now
than
I
can.
But
you
know
when
you
are
using
vendors,
such
as
that
say,
Red,
Hat
or
even
IBM.
There
has
there's
an
there's,
an
intimate
relationship,
and
there
is
an
incoming
stream
of
information
towards
you,
like
IBM,
will
tell
you.
The
other
mainframes
are
gonna
get
updated
on
this
date.
B
B
We
have
to
explain
that
time
and
time
again
and
even
then
they're
like
okay,
it's
cool
story,
but
what
that
trust
level
or
with
that
recognition
of
an
entity
existence
actually
change
the
ways
of
working
and
impact
to
the
level
of
Lucas,
saying
you
get
a
stream
of
information
from
a
source
that
you
trust
and
then
you
actually
do
the
extra
work
or
change
the
roadmap,
because
if
you
don't,
then
we
haven't
solved
the
problem.
I.
G
Think
it's
about
surfacing
surfacing
risk
I
mean
it's.
Obviously
it's
an
organization
whether
they
do
something
about
it
or
not.
But
if
the
least
they've
got
visibility
of
it,
then
they're
informed
and
they
can
make
an
informed
decision.
It
may
be
that
the
the
financial
pressures,
the
commercial
pressures
prevent
them
from
doing
something
returns.
Their
organization
would
consider
essential.
B
Could
you
give
a
more
concrete
example,
so
I
mean
I,
don't
want
to
keep
talking
about
updates
and
versions,
but
in
the
context
of
the
conversation
we
just
had
total
cost
of
ownership.
You
know
being
up
to
date
and
committing
back
and
contributing
back
to
projects
or
packages
or
getting
sort
getting
information
that
can
help.
You
change
your
work.
If
you
take
all
this
information
now
and
go
to
your
p.m.
or
organizations
or
you
go
to
your
you
know,
engineering
management
teams
or
a
business
leadership
and
say
hey:
can
we
change
our
ways
of
working?
B
Can
we
adjust
our
roadmaps
based
on
some
data
point?
Can
we
you
know,
invest
better
and
contributing
back
to
open
source,
specifically
around
the
libraries
that
we
use?
What
would
be
the
pushback,
because
if
there's
something
in
the
node
foundations
or
the
team
behind
building
node
can
help
you
with
data
points
around
that,
then
you
can
take
those
data
points
and
perhaps
do
something
with
it.
I
think
for
us,
like.
L
The
biggest
my
biggest
point
and
I'm
brand
new
into
making
these
argument,
but
everything
at
TELUS
relates
around
the
business
case
for
why
it
is
better
than
what
is
currently
there
and
anything
that
can
help
give
that
sort
of
the
executive
summary
of
like
this
upgrade
is
better
because
of
X,
and
you
know,
diluted,
sale,
trial
and
delivering
value.
If
we
like
shutting
down
all
nodes
instances,
because
there's
security
risk
is
great
like
that
seems
to
be
a
really
clear
argument
that
I
can
land
at
any
given
time
and
can
create
space
to
do
work.
L
But
that's
a
really
terrible
like
if
you
don't
do
this
terrible
things
will
happen.
It's
not
a
great
way
to
have
a
conversation
ongoing
basis
and
doesn't
help
convince
the
argument.
So
it
proactively
move
forward
to
versions
that
only
in
sort
of
end-of-life
version
conversation,
but
that
sort
of
conversation
about
what
at
the
enterprise
level,
new
versions
like
new
versus
node
will
enable
to
do
offer
for
us.
I
think,
is
a
really
useful
thing
that
the
foundation
can
have
a
like
media
package
for
sort
of
yeah.
G
Yeah
I
mean
they're
making
the
business
case
because
you
want
to
remove
some
shims
that
you've
got
and
because
they're
due
you
don't
need
them
in
a
newer
version
or
making
the
case
because
you,
you
know,
there's
a
more
performant
language
feature.
It's
always
a
more
positive
stories
that
have,
but
unless
there's
a
commercial
imperative
for
that
particular
language
feature
or
performance,
the
unfortunately
I
think
always
the
security
items
Trump
the
list
you
know,
but.
B
If
you
have
the
data
points,
so
maybe
a
key
takeaway
could
be
is
like
hey.
If
we
have
those
data
points,
we
can
actually
get
some
value
out
of
it
and
then
the
takeaway
will
be
for
part
of
the
node
work
to
go
and
actually
try
to
generate
those
data
points
as
part
of
releases
and
as
part
of
other
tool
sets.
Potentially
I
will.
J
Add
we
already
have
a
benchmarking
group
who
generates
some
charts
the
challenges,
all
those
things
I
think
could
be
very
valuable.
We
would
just
need
more
people
to
engage
to
help
make
them
happen
because
I
know,
based
on
the
current
people,
who
are
involved,
we're
not
going
to
be
able
to
to
do
that,
but
it
does
sound.
You
know.
So
that's
where
like,
if
it's
a
value
to
businesses,
if
we
can
somehow
get
the
enterprise's
to
come
in
and
help,
and
that
works
two
ways
when
it
makes
sure's
that
what's
being
generated
is
actually
useful.
J
G
One
of
the
things
that
we
do
is
we
benchmark
ourselves
so
we'll
run
a
run
up
note
no
day
and
ruin
all
our
unit
tests
and
integration
test,
Suites
against
it
for
a
given
product
that
we
want
to
upgrade
and
then
we'll
run
out
on
version
10
and
and
then
we'll
say
to
people
that
this
is
the
difference
and
I.
Think
that's
where
you
can
kind
of
you
know
really
reach
the
benefit
there.
G
I
don't
know
if
there's
any
way
of
making
that
easier
to
do
for
people,
I
think
you're
always
going
to
have
to
implement
your
own
benchmark
in
there
to
a
certain
degree
and
the
packages
for
doing
that,
whether
you
can
do
it
in
a
more
general
way
that
isn't
specific
to
your
implementation.
I
think
you're
always
gonna.
Ask
the
question:
yeah,
that's
great
I
can
see
it's
like
20
percent
faster,
but
how
much
faster
is
it
on
our
app.
B
Yeah
I'm,
just
thinking
that
point
as
Steve
was
making
of
what
information
can
the
node
teams
provide
up
front
that
make
that
journey
easier
and
maybe
like
yeah?
Maybe
it's
not
like
drill
down
details
benchmarks,
but
just
including
the
benchmark
data
as
part
of
a
release.
Note
might
be
just
one
step
to
get
there
right.
Yeah
I
mean
here.
K
B
G
In
that
you
look
at
the
difference
between
say
version,
a
and
version
10,
and
you
know
int
in
set
benchmarks
you
getting
this
much
more
performance,
so
therefore
it
might
be
worthwhile
us
exploring
what
the
benefit
is.
Gonna
be
first
on
our
code
base
sort
of
indicative
things
that
can
kind
of
in
your
direction.
Yeah.
I
If
you
haven't
have
a
web
application,
you
know
doing
a
lot
of
stuff,
you
know,
I,
oh
you
know
getting
reading
databases,
you
know
the
the
benefit
you
get
from
the
node
application
is
pretty
small
right.
You.
Typically
it's
tough
to
really
differentiate
the
comparisons,
something
which
is
coming
from
the
node
foundation,
but
this
is
the
improvement,
should
be,
is
helpful.
A
0-6
was
always
getting
faster
than
zero.
Eight,
we
did
some
reacting,
which
ended
up
making
the
benchmarking
that
we
were
the
micro
benchmarking
that
were
checking
drop
off
and
like
the
side
effect
of
that
was
a
lot
of
people
where
they
were
just
like
yeah
yeah
we're
going
fast
all
the
time
and
like
updating
you
know,
always
we're
like
no
we're,
not
gonna
update
we're
gonna
wait
for
the
fast
to
come
back
around
and
it
didn't
for
a
long
time.
A
Yeah
yeah,
so
we
set
that
expectation
that
it's
always
gonna
do
faster
than
you
know.
Kind
of
the
the
core
team
needs
to
be
well
aligned
that
you
know
that
that's
a
metric
that
we're
trying
to
hit-
or
we
need
to
manage
expectations
that
you
know
we're
just
sharing
that
information
for
you
you're.
You
know
contacts
and
not
expect
you
to
drive
decisions
on
it.
It's.
L
L
I
thought
there
was
a
really
interesting
story
which
I
saw
circulating
on
twitter,
twitter
or
not,
which
is
that
you
know
we
can.
We
can
take
the
moji
for
a
huge
amount
of
security
because
it
makes
people
upgrade
like
iOS
and
Android
versions,
yet
to
do
ystem,
og
and
like
as
silly
as
that
is
it's
actually
a
really
compelling
executive
story
like
what's
the
shiny
thing.
That
is
the
compelling
story
to
let
people
want
it,
regardless
of
whether
it
is
a
useful
enough
and
another
thing,
perhaps
that
the
node
foundation
can
help
with
so.
B
I
J
G
J
It's
a
I
think
that's
a
good
idea
would
just
be
good
to
have
like
concrete
things
that
are
working
or
not
working
in
terms
of
because
I,
don't
think
the
information
is
completely
absent.
It
may
just
not
be
communicated
in
a
way.
That's
gonna,
resonate
or
publicized
enough,
which
would
be
interesting
to
know
as
well.
B
So
I
think
we're
running
out
on
the
hour.
I
really
appreciate
all
of
you
and
the
conversation
here.
I'm
gonna
ask
a
couple
of
quick
questions.
Do
you
think
this
is
something
we
can
do?
Maybe
every
two
or
three
months
or
more
cadence
or
less
cadence
or
less
frequency
or
more
frequency
interesting
in
your
thoughts
quickly,
otherwise,
I
think
what
we're
gonna
be
doing
is
taking
all
this
conversation
summarizing.
B
It
probably
sharing
sharing
it
back
with
you,
but
also
with
all
the
different
working
groups
and
trying
to
see
like
where
the
right
fit
for
some
of
this
conversation
might
be
like
just
immediately
talking
about
okay
release
notes,
maybe
more
kind
of
action-oriented
data
points
that
teams
can
take
and
do
other
ideas.
You
know
standard,
emoji,
library,
great
I,
don't
know
cadence
wise
any
thoughts.
I'm.
I
Really
interested
in
the
package
maintenance
part,
you
know
some
of
those
standard
packages
like
Express
and
all
you
know
we
have
recent
challenge
which
we
are
trying
to
solve.
Is
you
know
our
logging
infrastructure
depends
on
CLS
because
you
know
the
API
is
we
want
to
pass
on
that
logging?
Is,
you
know,
ID
the
correlation
ID
down
the
line,
and
you
know
we
want
to
make
a
change
in
Express
so
that
you
know
the
store
implementation
of
X
possession
can
get
somehow
the
request
information,
but
you
know
that
changed
probably
would
never
get
through.
I
J
It's
like
how
do
we
bring
together
the
you
know,
not
just
the
enterprises
but
the
users
of
these
packages
to
help
you
know
one
make
it
easier
to
contribute
back,
because
it's
usually
not
that
the
package
maintainer
don't
want
to
help
or
do
it,
but
they've
got
other
priorities
or
their
constraints,
and
it's
a
matter
of
like
so.
How
do
we
bring
the
community
together
to
improve
that
situation?
But
so,
if
you
wanted
to
join
in
the
conversation
on
that
specific
front,
I
think
that's
a
good
place
to
get
engaged.
J
G
B
Have
to
go
and
actually
have
those
conversations
in
different
working
groups,
giving
some
of
the
topics
we
discussed
and
then
come
back.
That
could
probably
take
a
cycle
I'm
more
than
happy
to
do
something
like
monthly
but
I.
Don't
want
to
leave
a
topic
hanging
and
actually
get
some
real
feedback
back
to
the
individuals
here
and
then
take
on
more
detailed,
deeper.