►
From YouTube: Public User Feedback Meeting - Enterprise Use Case
Description
B
A
So
you
know
we
we
had
a
few
more
folks
expected
to
join
us
and
primarily
have
aquaeden
asura,
the
principal
architect
of
tellus
with
us,
so
it's
going
to
be
a
little
bit
less
round
table
than
we
normally
would
and
I'm
gonna
go
ahead
and
pull
up
my
screen
here
and
get
my
agenda
up.
So
we
can
all
refer
to
the
core
questions
here.
A
So
in
our
user
feedback
sessions
we,
you
know
when
we
have
a
bit
bigger
crowd
where
we
found
that
we
have
to
do
a
fair
amount
of
time
management
and
you
know
making
sure
that
everyone
has
their
time
since
we're
you
know,
have
a
fairly
broad
representation
of
folks
across
the
foundation
this
morning
and
a
knock
bed.
You
know
I'll
let
that
linger
a
little
bit
longer,
but
you
know
I've
got
the
agenda
up
and
they
all
want
one
ever
wanted
to
introduce
themselves,
and
you
know
the
questions
there
are.
Who
are
you?
A
Where
do
you
work?
What
do
you
do
and
then
I'm
gonna
split
out
the
describe
the
enterprise
use
case?
So
what
we'll
come
back
to
that
so
I'm
gonna
go
ahead
and
go
around
my
screen.
So
I'll
start
off
I'm
Dan,
Shaw
I'm,
an
independent
consultant
and
I
run
my
mouth
I.
Do
this
professionally
talking
to
folks
and
helping
grow
the
market
around
oh.just
and
the
web
platform?
C
D
You
say:
I
work
at
TELUS
we
are
a
Canadian
telecom
business
with
all
the
glories
and
the
complications
that
come
with
the
telecom
industry.
We
are
a
no
js'
adopters
and
heavy
users
in
all
of
our
technologies
and
stacks
and
myself
have
been
involved
in
ojs
from
years
ago,
as
both
the
user
contributor
and
advocates.
Wherever
I
can.
E
Michael
Dawson
I
work
for
IBM
I'm,
my
BMS
community
lead
for
nodejs
active
in
the
core
project
and
so
I'm
on
the
technical
steering
committee
and
acting
this
the
chair,
as
well
as
being
a
member
of
the
community
committee
and
very
interested
in
in
sort
of
helping
to
close
the
gap.
If
there
is
one
between
end
users
and
the
technical
project.
So
that's
why
I'm
here.
F
A
B
A
D
D
You
know
even
transitioning
a
massive
amount
of
users
from
one
system
to
another
or
database
of
other
the
telecom
side
of
it,
though,
there's
there's
physical
hardware
impact
on
that
as
well.
You
know
when
we
talk
about
you,
know
people
signing
up
even
on
like
the
website
and
you
know
creating
a
new
account
that
has
to
propagate
its
way
all
the
way
down
to
provisioning
physical
networks
and
IP
addresses
and
and
following
the
packets
along
the
actual
network,
for
that
account
to
be
activated
for
your
home
internet
to
reach
your
home.
D
So
what
that
means
is
there's
a
lot
of
technologies.
Let's
say
that
have
been
around
for
well
over
30
40
years
that
we
just
simply
cannot
easily
replace
so
that
also
propagates.
This
way,
all
the
way
back
up
to
even
our
software
layers
and
our
ability
to
integrate
and
our
ability
to
change
the
dynamics
of
how
our
technologies
and
software
interact
with
each
other.
So
that's
kind
of
thing,
the
big,
the
big
kind
of
context,
that's
important
to
kind
of
keep
in
mind
in
a
nice
on
a
sort
of
telecom
technology.
D
The
other
thing
is
also
the
the
broad
spectrum
of
quote:
unquote,
businesses
that
we
are
in
as
a
talk
on
business,
so
typically
people
think
of
telecom
business.
As
you
know,
the
ISP,
the
internet
provider,
the
cellular
cellular
network
provider,
perhaps
your
home
TV,
but
you
know,
interestingly,
like
and
I-
have
a
good
story
about
this.
I
keep
discovering
different
parts
of
the
business
and
different
business
units
in
the
company
that
I
am
shocked
and
surprised,
as
we
are
in
that
business.
D
A
very
simple
example
of
Telus
and
again
Telus
is
a
small
medium-sized
telecom
in
a
country
that
is
Canada.
That
is
also
you
know
in
terms
of
population,
we're
talking
about
30
million
34
million
people
versus,
for
example,
the
u.s.
of
300
plus
people.
So
even
our
size
of
the
business
is
minut
compared
to
a
the
u.s.
D
telecom
business,
but
I
keep
discovering
different
parts
of
what
we
do
outside
of
the
norm
of
ISP
technologies
and
cellular
networks
like
we,
we
actually
offer
b2b
services
and
products
that
we
go
in
and
retrofit
entire
buildings
with
networks
for
business
customers.
We
have
a
studio
part
of
our
business.
We
actually
do
some
video
productions,
which
is
interesting.
We
have
a
VC
part
of
the
company,
we
actually
invest
in
other
companies.
D
We
actually
operate
multiple
brands
of
our
telecom,
not
just
the
one
brand,
so
we
have
subsidiaries
and
other
kind
of
smaller
brands
of
our
telecom
business
that
we
operate
as
well.
We
we
are
in
the
business
of
IT,
consulting
as
well
and
outsourcing.
So
actually,
there's
part
of
the
business
call
tell
us
International
and
it's
kind
of,
like
the
outsourced,
call
center
business
as
well
as
tech
and
IT
support
business.
D
In
fact,
somebody
told
me
from
the
Google
team
and
I
haven't
been
able
to
find
this
internally,
yet
that
if
you
actually
call
the
GCP
support
tech
support,
you're
actually
talking
to
a
tell
us
human
at
some
level,
which
is
interesting
because
I
told
them
if
I
switch
to
GCP
and
I
need
support.
I
just
talked
to
myself.
D
So
it's
addressing
the
telecom
business
is
big
and
wide
and
it
covers
a
lot
of
things
and
at
the
same
time,
for
some
reason
we
tend
to
compete
with
everybody.
So
we
are
in
competition
with
companies
like
Netflix,
as
it's
probably
painfully
aware,
there's
the
old
cable
business
there's
also
the
new
IPTV
business
and,
of
course,
companies
like
Netflix
have
the
streaming
business
that
competes
with
all
of
that,
we
could
bid
compete
with
companies
like
Google,
even
where
you
know
Google
is
building
fiber
networks
and
and
spreading
Internet
connectivity.
D
Even
Facebook
is
getting
into
that
business
as
well.
That's
in
direct
competition
with
us
and
the
examples
just
keep
on
going
and
if
you
think
of
where
the
telecom
business
used
to
be
like
not
that
far
ago,
just
10
15
years
ago,
I
remember
where
the
telecom
was
the
one
that
decided
what
software
hardwood
hardware
you
get
on
your
phone.
A
Good
intro
yeah,
that's
great
intro
and
I
love
the
fact
that
you
know
many
times
when
we're
talking
about
the
tech
knowledge
as
in
the
enterprise
and
that
they
are
the
technology
aspects
of
that
we're
talking.
You
know
we
tend
to
talk
about
scale
right.
We
tend
to
talk
about
just
you
know
the
number
of
instances
or
something
like
that,
but
so
much
of
the
enterprise
experience
is
really
the
different
business
units
and
all
that
collaborating
and
competing
together.
D
I'm
part
of
a
team
within
the
company
called
Telus
digital,
and
our
purpose
in
our
mission
is
to
digitize
the
hundred-year-old
telco.
That's
our
tagline.
So,
given
all
the
context
that
I
just
talked
about
what
we
are
coming
coming
to
the
table
with
is
modern
software
practices
and
more
software
technology
and
looking
of
how
we
can
modernize
the
entire
business,
both
from
our
cheap,
all
the
way
from
user
experiences
down
to
systems
and
technologies
and
infrastructure
and
somewhere
in
between
there.
D
There
is
obviously
things
like
ojs,
so
if
you
think
about
it
from
the
user
experience
point
of
view
or
our
case
customer
interact
as
we
refer
to
them
and
talking
about
the
web
talking
about
mobile
talking
about
application
interfaces,
nodejs
is
obviously
dominating
that
space,
so
the
choice
is
made
for
us.
In
that
context,
it's
easy
enough
to
say
that
when
we
are
building
things
on
the
web,
no,
the
JavaScript
is
the
platform.
There
is
a
no
other
choice.
D
To
be
honest
and
be
it's
it's
it's
clear
enough
that,
where
you
want
to
invest
you're
hiring,
you
want
to
invest
your
skillset
growth.
You
want
to
invest
your
contribution
back
to
the
open-source
community,
that's
good
enough
where
that
happens,
and
how
that
can
be
effective
from
the
systems
and
API
is
an
integration
layer.
D
So
if
I'm
talking
to
my
peers
and
the
home
security
line
of
work
or
the
healthcare
infrastructure,
that's
actually
provided
as
the
applications
for
our
healthcare
professionals
across
Canada,
then
there's
a
whole
different
level
of
complexity
involved,
at
least
from
the
system's
point
of
view.
So
when
you
look
at
technologies
like
nodejs
and
compare
that
to
the
traditional
kind
of
enterprise
IT
world
of
let's
say,
Java,
and.net
and
kind
of,
depending
on
the
kind
of
business
you're
in
the
backend
technology,
they
used
to
refer
to
them.
D
The
challenge
there
is
entirely-
and
mostly
from
my
perspective,
is
in
the
the
scale
of
the
talent,
not
the
scale
of
the
technology.
This,
let's
be
frank,
and
let's
be
honest,
programming
language
wise,
like
the
neverending
war
of
programming,
language
choices.
At
the
end
of
the
day,
you
can
really
build
anything
you
want
with
any
programming
language.
You
want.
The
effort
might
different,
but
the
thing
that
makes
it
them.
It
makes
the
effort
harder
or
makes
the
o
makes
or
breaks.
D
The
bank
is
the
level
of
apatite
from
the
tech
community
to
actually
work
in
these
technologies
and
your
access
to
two
skilled
humans
in
the
space
to
help
you
scale
to
the
level.
You
ask
a
lot
so
if
we
want
to
be
a
competitive,
telco
business
in
the
21st
and
22nd
century
and
continue
to
be
competitive
with
our
markets
and
all
these
different
things
that
I
mentioned
that
we
work
in,
we
cannot
miss
rely
on
the
technology
that
was
there
from
twenty
something
years
ago.
D
We
have
to
adopt
the
latest
and
the
greatest
and
be
actually
part
of
part
of
the
change
on
the
technology
itself.
So
open
source
is
key
for
that
and
again
JavaScript
and
ojs
are
in
the
heart
of
it.
So
we
can't
just
be
on
proprietary
systems
and
proprietary
technologies.
We
have
to
be
open
source
because
that's
how
we
actually
attract
the
right
talent
and
that's
how
we
actually
grow
our
team.
D
So
that's
where
how
we
can
actually
scale
in
terms
of
our
ability
to
impact
a
technology
evolution
itself,
so
we're
in
the
business
of
digital
transformation
and
digital
transformation
starts
with
the
humans
and
and
if
we
don't
have
the
right
culture,
then
technology
and
architecture,
it
doesn't
really
matter.
I
said
this:
on
Twitter
a
while
ago
is
like,
if
you
you
can
have
the
most
beautiful
architectural
diagrams
and
the
most
beautiful
system
designs
that
you
want.
But
it's
it's
like
you
know,
having
a
beautiful,
the
architected
building.
A
So
I
saw
that
tyranny
had
a
question,
and
it's
a
great
moment
to
you
know
have
to
have
questions,
though
I
do
want
to
emphasize
that
it
was
a
great
moment
to
you
know,
jump
in,
and
you
know,
ask
questions
about
what
occupy
set
up.
We
are
going
to
be
going
into
what's
working.
What's
not
so
just
you
know
make
sure
you
give
space
with
the
intensity
yeah.
F
So
you
touched
on
something
that
I've,
you
know
a
lot
of
the
people
who
I've
talked
to
in
the
enterprise
that
are
using
node
talked
about
a
lot.
It's
like
the
one
thing
I
always
hear
from
them
is
how
can
I
hire
more
know
developers
so
I'm
curious?
What
your
kind
of
experiences
with
that,
because
you
said
you
know
this
is
a
space
where
people
you
know
developers
want
to
be
and
that
they
are
already
kind
of
there.
F
D
So
it's
interesting
for
us,
because
the
company
is
not
in
one
location.
It's
across
Canada.
Our
primary
offices
are
in
Toronto
and
Vancouver,
and
what
we,
what
I've
found
again
from
a
higher
perspective
in
Toronto,
is
much
easier
for
us
to
go
into
the
marketplace
and
actually
just
talk
about
our
technologies
and
the
fact
that
we
are
using
nodejs
and
we
are
actually
building
things
in
a
modern
sense.
D
It
wasn't
the
same
in
Vancouver,
because
I
think
that's
much
more
more
about
like
competitive
competitive
space
in
the
west
coast,
because
in
Vancouver
you
have
Seattle
in
the
valley
very
nearby
and
those
component.
Companies
in
the
US
are
more
competitive.
That
way,
they
just
fly
people
out
and
pay
them
all
the
money
they
want.
So
that's
harder,
but
nothing
to
do
with
the
technologies
or
anything
else.
That's
just
the
competitive
space
internally.
D
We
do
have
kind
of
the
mentorship
set
up
that
we
try
to
do
and
growing
people
in,
and
we
actually
have
seen
massive
success
in
in
our
you
know:
let's
call
them
the
IT
teams
that
have
been
working
with
Java
technologies
and
old-school
technologies
and
kind
of
the
ESP
systems.
We've
seen
massive
success
in
bringing
those
folks
over
and
actually
have
them
start
building
things
in
nodejs,
and
we
have
this
thing
internally.
We
call
call
it
the
digital
platform.
D
It's
build
entirely,
a
node,
it's
just
a
collection
of
infrastructure,
API,
tooling,
front-end
components,
kind
of
management
and
NCI
CD
lifecycle,
tooling,
all
put
together.
We
just
label
it
as
the
digital
platform.
We
have
IT
teams,
come
and
actually
build
on
a
digital
platform
now
and
and
their
impact
on
on
delivering
the
work
that
they
need
to
deliver
and
their
ability
to
actually
feel
more
productive
at
work
is
actually
very
measurable
and
very
visible
to
their
leadership
as
well.
D
You
get
them
to
start
becoming
active
and
kind
of
build
their
skillset
in
it.
Then
the
natural
next
step
and
progression
is
to
contribute
back
and
and
and
that's
I
think
that's
one
personal
goal
for
me
and
I
think
it's
also
uniquely
achievable
in
a
company
our
size,
because
I'm
talking
about
my
immediate
team
is
let's
say
it's
three
hundred
and
fifty
technologists,
but
my
community
of
practice
within
the
business
is
over
to
three
thousand
people
of
technologists
and
developers.
D
So
if
we
can
actually
get
those
two
hundred
two
thousand
people,
three
thousand
people
at
some
point
in
the
subsea
some
shape
or
form
contribute
back
to
the
open-source
community.
That's
that's
unique
that
doesn't
happen
often
unless
you're
a
company,
the
size
of
Google
or
Facebook
or
perhaps
IBM.
So
this
is
where
I
want
to
start
seeing
the
maturity
level
of
the
technology.
Adoption
and
the
usage
of
the
the
language
actually
start,
making
its
way
back
into
the
open-source
community
and
I.
A
E
A
D
I
can
talk
forever
about
the
people
problem
and
the
scaling
with
the
old
problem,
but
that
can
talk
even
longer
about
what's
working
or
it's
not
working
and
I.
Think
the
let's
just
use
the
most
recent
most
immediate
example
like
we
just
launched
not
just
and
amazing,
I
can't
use
it
yet
and
the
reason
I
know,
but
I
want
to
use
it
right.
So
my
challenge
is
in
being
like
I
said:
I
have
a
community
of
practice.
D
That's
you
know
over
2,000
people,
developers
and
people
who
are
learning
and
or
experts,
but
I
can't
use
it
in
a
professional
sense.
That's
not
the
point
to
your
point
then,
like
you,
it's
not
LCS.
Yet
we're
not
there.
Yet,
where
can
I
actually
leverage
those
two
thousand
humans
and
use
the
most
recent
version
so
that
we
can
provide
that
feedback?
What
does
that
mechanism
look
like
and
short
of
people
working
on
site
projects
and
doing
things?
D
So
it's
more
about
like
the
there's
no
structure
to
it,
we
can
go
and
do
something
and
just
ad
hoc
build
and
try
things,
but
maybe
there
is
something
the
the
foundation
can
can
kind
of
structure
so
that
organizations
such
as
ours
or
others
can
actually
feel
that
they
can
actually
do
something
fast
and
early
as
opposed
to
just
the
standard
mode
of
oh
okay,
no
J
stands
out
great,
we'll
just
wait
for
the
LTS.
Let
me
know
when
you
guys
are
ready
right
did.
D
As
a
business,
I
have
a
widow
LTS
individually,
I've
been
playing
with
it
for
a
long
time
sure,
but
that's
not
the
same
thing
right.
So
as
a
business
I
have
no
kind
of
I,
don't
know
if
structure
is
right.
Word
I,
just
don't
have
any
mechanism
that
I
can
be
useful
to
the
foundation
and
in
trying
something
earlier
right
channel
exactly
I,
don't
have
a
feedback.
E
D
E
A
few
things
that
come
to
mind
would
be,
for
example,
if
you
have
a
set
of
regression
tests
and
you
ran
those
on
you
know.
Obviously,
you're
not
gonna
put
into
production,
but
if
you
ran
those
regression
tests
using
no
ten,
that
would
be
something
that
I
could
see
be
quite
useful,
as
did
it
did
it,
you
know,
does
anything
new
come
up
and
if
the
does
you
know
feeding
that
back
into
the
project.
D
E
A
Just
just
you
know
to
add
a
little
bit
of
context
for
those
who
aren't
familiar
with.
You
know
LTS
and
current,
and
you
know
the
usage
patterns
around
those
right.
So
we
have
this.
What
is
it
six
months
current
release
and
that
is
generally,
you
know
considered.
You
know
for
early
adopters
or
folks
that
want
the
other
latest
features,
and
you
know
eventually
we
take
that,
and
you
know
that
that
uses
the
active
usage
of
current
really
o
enables
us
to
deliver
that
that
stability
and
reliability
when
we
get
to
the
the
LTS
release.
A
So
you
know
oftentimes,
you
know
the
enterprise
approach.
Is
you
you
wait
three
or
four
releases
after
the
the
first
release
to
let
you
know
some
of
the
the
funk
go
out,
but
I
like
the
framing
up
at
that
the
the
framing
of
you
know,
there's
ten
ten
zero.
You
may
not
be
putting
into
production,
but
you
know,
is
everything
working.
B
E
A
I,
never
I've
never
actually
realize
I'm
almost
embarrassed
to
admit
I've.
Never,
actually,
you
know
thought
of
that
as
a
point
to
engage
the
enterprise
users,
you
know
I'd
always
kind
of
assumed,
yeah
yeah,
you
know
current,
you
know
let
the
you
know
the
startups
and
you
know
more
independent
and
aggressive
teams.
You
know,
go
and-
and
you
know,
use
that,
but
there's
absolutely
no
good,
sensible
practices
that
that
we
can
do.
And
you
know
we
have
some
great
examples
in
the
past.
You
know
at
boxer.
A
We'd
always
you
know
we
just
had
so
much
data
throwing
through
the
platform.
You
know
comparative
lead
it
to
the
other
sets
of
users.
You
know
some
time
ago,
and
you
know
when
you
know
we've
run
know
the
latest
versions
of
note
on
the
system.
We
would
really
be
able
to
see
you
know
different
behaviors,
then
some
of
the
other
use
cases
that
were
out
there.
That's
that's!
That's
pretty.
E
Yes,
I
mean
I,
guess
what
I'd
suggest
is
you
know
why
don't
we
take?
That
is
one
of
the
topics
for
discussion
in
one
of
the
follow-up
meetings
in
terms
of
like
we
can,
you
know
we
can
all
think
about
it,
come
up
with
a
list
and
then
sort
of
get
back
together
to
sort
of
go
through
brainstorming
and
then
figure
out
how
we
publish
publicize
that
sort
of
make
it
a
formal
ask
almost
from
the
project
yeah.
A
In
occupied,
if
you
you
know
with
that
sort
of
inspiration,
you
know
think
of
how
you
could
turn
that
into
a
process
internally
and
want
to
create
an
issue
to
sort
of
help
everyone
else
frame
their
you
know
their
approach.
That
would
be
amazing,
so
invited
there
and
we'll
feed
that
this
question
of
what
can
you
do
back
into
our
following
sessions?
Yeah.
D
Absolutely
and
I
mean
again
that's
a
good
example
of,
like
reactive,
reactive
type
of
action.
So
if,
let's
say
the
new
release
comes
out,
there's
some
data
you
collect
about
regression
or
whatever
you
know
what
what
company?
What
can
companies
like
us
do
to
help?
There's
also
things
like
discovery
and
kind
of
exploratory
things
that
I
don't
know?
D
F
I
was
hitting
this
yesterday
or
I
was
playing
with
some
stuff
at
our
own
products,
but
you
know
I
I'd
be
curious
to
see
how
many
times
you
hit
new
buffer
in
your
own
code
or,
like
you,
know
the
deprecations
that
we
are
shipping
before
they
like
you,
don't
want
to
be.
You
don't
want
to
find
out
about
that
once
we
go
LTS
like
getting
that
kind
of
information
of
like
these
are
the
major
major
changes
that
might
affect
you.
F
Is
there
anything
additional
on
top
of
what
shipped
in
note
n
that
we
can
do
to
kind
of
lessen
this
barrier
or
create
a
better
path
for
you
to
upgrade
and
like
I,
don't
think
that
kind
of
deprecation
happens
often
like
in
my
experience
it
hasn't
but
getting
feedback
on
like
okay?
If
you
just
run
this
with
your
app,
what
like
does
it
error?
I?
Would
a
bunch,
or
does
it
just
run
fine?
That
kind
of
stuff
would
be
super
important
and
helpful
contacts,
I
think
yeah.
E
So
you
know
how
do
they
put
that
question
together?
How
does
it
get
to
the
enterprise's?
How
do
we
get
the
feedback
and
so
forth?
So
yeah
I
think
that's
one
of
the
things
that
we
should
work
together
on.
You
know
formalizing
that
so
that
it's
easy
right.
You
know
we
come
to
make
a
hard
decision
and
we
say:
okay
well,
wait
a
sec.
We
can
get
more
information
which
always
helps.
Let's
go
ask
this
group
over
here
and
that's
that's
part
of
the
motivation,
I.
A
Think
that
making
it
easy,
for
you
know,
individuals
like
augment,
that's
going
to,
you
know,
go
and
you
know
it's
like
the
the
you
know,
teams
to
go
and
do
this.
You
know
we
have
to
recognize
that
you
know
he's
you
know
potentially
bringing
to
bear.
You
know
hundreds
of
people
that
are
gonna,
go
and
give
him
data
and
and
and
then
you
know,
we
need
it
not
to
be.
You
know
a
huge
burden
of.
B
A
D
F
D
E
D
And
that's
again,
that's
for
you
to
if
you
provide
this
structure
and
you
provide
kind
of
a
a
playbook
for
companies
to
say,
hey,
here's
some
things
you
can
do
maybe
go
search.
Your
codes
for
the
following
tell
us
how
many
times
it's
used.
What
context
is
it's
used
in
I
can
do
that.
It's
easy
and
I
can
provide
you
that
data
and
then
that
helps
inform
you
know
the
rest
of
the
conversation
that
you
want
to
actually
have
yeah.
A
I
think
that
really
balances.
You
know
the
the
you
know,
the
voices
that
we
hear
where
it's
it's
one
individual
with
a
thousand
repos
and
that's
an
incredible
burden.
But
you
know
that
it's
inverted
there.
In
the
enterprise
case,
where
you've
got,
you
know
the
the
repos
and
then
a
thousand
people
right.
E
A
Actually
go
and
you
know,
work
those
issues
and
you
know
I
know
from
from
experience
document
is
you
know,
he's
got
everything
automated
and
you
know
set
up
with
CI
CD.
So
you
know
when
you
have
that
level
of
you
know,
confidence
in
infrastructure
that
you
can
lean
on,
then
you
know
you
can
make
the
simple
code
changes
and
you
know
the
rest
of
the
infrastructure
helps
you
do
the
rest.
The.
E
The
other
thing
is
I
mean
I've
had
was
talking
about
more
proactive
things,
that's
still
a
sort
of
responsive.
We
have
some
questions.
Let's
go
ask
to
get
some
more
information,
which
is
good,
I,
think
on
the
the
more
proactive
I
mean
I,
think
working
together
to
get
a
better.
You
know
understanding,
documentation,
direct
feedback
on
the
key
things
for
the
enterprise.
You
know,
for
example,
we
certainly
have
our
views.
You
know
working
at
IBM.
We
have
our
views
of
what's
important
for
the
enterprise,
but
I
think
as
a
project.
E
We
can
work
more
closely
with
the
companies
to
sort
of
highlight
what
are
the
current
things
are
the
most
important
and
then
look
at
where
you
know.
Is
it
that
no
js'
is
you
know
at
a
hundred
percent
on
those
or
is
it
at
fifty
percent
and
that
there's
a
gap
that
you
know
we
should
look
at
and
look
at
filling
and
usually
those
are
the
kind
of
things
you
know.
They're
not
filled
because
it's
gonna
be
a
longer
term
effort
to
fill
those
and
to
say,
okay.
E
Well,
yes,
there's
a
gap
here
and
you
know
for
the
longer-term
success
of
the
overall
project.
We
need
to
work
on
something:
that's
you
know
bigger
longer
scope,
complicated,
but
it's
important
because
we
can
you
know
we
get
the
feedback
from
the
the
people
with
the
large
deployments
to
say:
okay,
yeah,
let's
go
work
on
this
particular
piece
and
there's
so
many
different
options
that
you
know
having
the
the
direct
feedback.
E
I
think
would
help
us
narrow
them
too,
and
and
also
maybe
you
know,
test
out
early
ideas
and-
and
you
know,
options
in
as
opposed
to
trying
to
make
some
of
those
up
because
I
know
often
we
come
to.
You
know
we're
looking
at
things
like
worker
support
and
it's
like
well
do
we
have
concrete
use
cases
and
places
where
we
can
validate
that
you
know.
That's
actually
useful
that
there's
going
to
be
a
benefit.
E
You
know
so
I
think
that's
another
area,
we're
sort
of
more
proactively
if
we
could
come,
as
you
know,
as
the
enterprise
group
could
come
together
and
sort
of
highlight
a
few
priorities
and
then
work
with
the
project
to
provide
the
you
know
the
use
cases
and
the
feedback
when
we
have.
You
know
ideas
and
things
to
try
out
yeah.
D
I
just
hit
on
a
couple
of
those
examples
you
mentioned,
like
you
know:
worker
support
well,
I'm,
running
everything
on
single
instance,
CPUs
and
docker.
So
are
we
gonna
get
too
much
of
a
benefit
on
that
right
and
speaking
of
docker
like
when,
when
when
security
patches
are
made
and
and
on
releases,
I,
don't
want
to
have
to
wait
a
full
day
for
the
security
patches
to
show
up
in
the
docker
image.
Like
that's.
D
That's
certainly
us
sitting
there
refreshing,
refreshing,
refreshing
waiting
for
the
docker
hub,
build
to
be
done
or
the
merge
on
the
must
be
completed
right,
that's
important
for
us,
because
when
people
see
security
alerts
go
out
in
the
in
the
community,
about
security,
important
security
patches
coming
and-
and
we
don't
have
an
answer
for
it-
that
makes
a
lot
of
people.
You
know,
grow
more
great
and
in
an
enterprise
setting
right
right.
That's.
F
E
Coordinated
with
the
docker
working
group
a
little
bit
better
on
that
yeah
I
mean
there's
already
been
a
discussion
on
that
front,
but
I
think
getting
more
of
that
feedback
helps
in
terms
of
framing
that
wait,
a
sec.
It's
not
just
you
know
it's
it's
getting
the
full
picture
on
who's
concerned
about
that
versus
the
well.
You
know
it's
only
a
day.
Maybe
it's
fine
kind
of
thing
right,
so
yeah.
D
Again,
give
you
a
little
bit
more
context
and
I'm,
not
gonna
hammer
at
this
point,
but
just
again
for
my
example
to
drive
deeper
like
when
the
blog
post
went
out
that
security
changes,
our
security
patches
are
coming
on
all
major
versions
and
it's
a
big
deal
and
everybody
needs
to
pay
attention,
guess
what
everybody
did
pay
attention,
including
VPS
and
Lex
security
organizations
within
our
teams
and
they're
all
like?
Oh,
my
god,
something
bigs
coming
right.
D
So
there
was
a
level
of
anxiety
that
was
generated
and
then,
when
the
announcement
was
made,
there
was
a
full
24
hour
period
before
we
can
actually
get
the
latest
docker
images,
because
that
was
what
we're
running
on
an
infrastructure
wise
and
then
because
we
wanted
to
use
the
official
ones
we
didn't
want
to
just
roll
our
own
and
then
that
doesn't
still
doesn't
mean
that
our
applications
have
all
been
entirely
patched
and
upgraded.
So
that
took
us
another.
Perhaps
48
hours
before
everything
is
updated
right.
D
So
you
know
right
now:
it's
more
communications
and
anxiety
that
happens
inside
an
organization
as
the
size
of
ours.
That
doesn't
necessarily
mean
the
burden
is
on
you,
but
what
can
you
and
we
work
together
on
so
we
can
have
a
better
structure
for
those
things
and
we're
happy
to
be
there
for
us.
Yeah.
E
E
Guess
it's
it's
the
in
there's!
There's
some!
You
know
there's
often
some
of
the
hard
trade-offs
is
like.
Would
you
prefer
to
get
it
later,
but
have
some
additional
notice,
or
you
know
anyway,
I
think
that
that's
a
good
topic
to
sort
of
you
know
make
another
folk
that
could
be
another
area
of
discussion
to
to
understand
and
drill
down
into
Michael.
E
Basically
works
fairly,
autonomously,
I
think
some
of
some
of
the
you
know
some
things
that
play
into
it
is
it's
not
just
us
in
terms
of
getting
those
built.
We
update
a
set
of
files.
Those
files
are
then
used
by
Doc.
You
know
once
they're
committed.
It
requires
a
build
by
the
doctor
infrastructure
to
get
the
new
images
out
so
I'm
not
sure
how
frequently
they
do
that
or
how
often
they
do
that.
D
This
particular
instance
I
remember
because
I
was
watching
the
photo
request.
It
was,
it
was
between
making
the
change
and
then
actually
merging
the
POE
request,
because
then
the
dog
or
dr.
Hopp
build
is
automated.
So
as
soon
as
that
merge
happened
picked
in
and
within
a
few
minutes
it
was
ready.
Okay,.
E
So
that
is
so,
if
it's,
if
it's
basically
something
like
that,
then
yes,
we
may
need
to
pull
in
you
know.
If
we
pulled
in
the
doctor
team
into
the
release
process,
we
might
be
able
to
close
that
gap
a
bit
so
yeah,
so
that
that's
that's
valuable,
valuable
feedback
and
and
yeah
I'll.
Take
that
back
to
the
next
security
working
group
meeting
and
see
if
we
can
see
what
we
can
do
on
that
front.
Yeah.
D
D
E
It's
a
soul,
it
comes
down
to
like.
Are
there
some
concrete
use
cases
where
people
will
see
real
benefits
and
will
those
benefits
be
better
like?
Can
you
get
significantly
better
benefits
by
using
you
know
a
multi-threaded
worker
implementation
versus
using
cluster
ins,
and
you
know
basically
having
multiple
instances
of
node.
A
Yeah
we
could
adopt
that.
Can
we've
adopted
that
constraint
because
it's
a
reasonable
one
and
a
good
one
and
it
matches
you
get
in
this
via
really
sweet.
Spot
of
you
know
a
single
compute
unit
in
your
orchestration
and
auto
scaling
right.
So
that's
that
that's
compelling,
but
I
wouldn't
necessarily
say
that
we
want
to
you
know
heavily
index
on.
You
know
single
process
as
a
primary
constraint
in
you
know
evaluating
that
the
the
technical
use
case
agreed
oxford,
enlightened
in
terms
of
his
understanding
of
the
platform
yeah.
E
Yeah
I'm
not
saying
yeah
I
think
it's
just
that.
There's
a
lot
of
there's
a
lot
of
different
options
and
again
the
feedback
of.
If
there's
lots
of
people
doing
in
one
particular
way
and
and
none
in
in
another
way.
That
can
inform
what
makes
sense
and
how
much
maybe
focus
we
we
try
and
put
on
a
particular
area
or
not
or.
E
A
We
have
a
few
more
minutes
here
and
you
know
I'd
like
to
you
know
just
just
feedback
in
we.
You
know
we've
basically
been
going
through.
You
know,
what's
working,
what
isn't
so?
How
could
any
other,
you
know
probably
room
for
one
more
topic
to
cover
in
what's
working,
what
isn't
in
the
enterprise
to.
D
Be
honest,
like
I'm,
just
relied
on
recent
examples
in
memory,
but
I'm
sure
if
I
go
back
and
think
deeper,
there
might
be
more
things.
So
it's
useful
to
have
this
kind
of
dialogue.
Ongoing
and
I
mean
again.
This
is
probably
not
news
to
you,
but
like
a
lot
of
the
day
to
day
concerns
and
in
terms
of
like
the
user.
Now
these
are
land
of
development
ends
up
being
around
libraries
and
NPM
and
those
kind
of
things
people
don't
tend
to
think
too
deep
about
the
the
core,
but
they
do
think
about
performance.
D
So
that's
important
and
then
debugging
performance
and
measuring
performance
is
definitely
key.
No,
no
there's
a
lot
of
libraries
that
help
with
that,
but
I
know
maybe
there's
something
there
around.
Whatever
happens
at
the
core
in
terms
of
surfacing
user
level,
performance
measurement
that
people
can
do
it
and
I
know
the
debugging
tools
exist.
Maybe
there's
a
little
bit
more
improvements
to
be
made
to
the
api's
for
these
tools
to
do
surface
that
data
on.
D
Personally,
yes,
on
different
libraries
and
benchmarks
that
I
ran
and
my
personal
stuff,
we
don't
have
that
level
of
that's
what
I'm
saying
and
I
don't
have
that
level
of
investment
in
a
consistent
matter
across
my
enterprise
level,
work
with
the
applications
and
the
teams,
primarily
because
it's
more
taxing
to
create
that
kind
of
level
of
benchmarking
across
projects
and
work
matter.
So
my
feedback
was
there
is
that
well,
is
there
improvements
to
the
debugging
api's
and
the
measurement
benchmark
benchmarking,
a
measurement
API
to
surface
that
data
better?
D
Because
right
now
you
have
to
you
know,
do
a
core
dump
and
then
you
have
to
collect
that
data,
and
you
maybe
use
some
visualization
tool
to
do
a
flame
chart
around
it
right.
Maybe
there's
some
more
investments
from
the
core
to
make
that
more
user
friendly
for
the
you
know,
none
initiated
or
the
non
advanced
developer,
who
is
gonna,
invest
a
lot
of
their
time
to
do
that.
Right.
E
Yeah,
okay,
I
I
was
I
was
coming
from
it
from
the
benchmarking
workgroup
perspective,
like
we've
tried
to
cover
some
of
the
key,
the
key
use
cases,
but
if
there's
some
that
are
falling
through
the
cracks
and
we're
actually
seeing
regressions
that
those
are
you
know
ones,
we
should
prioritize
what
you've
just
mentioned.
I
think
comes
under
the
work
from
that.
The
diagnostic
working
group
is
working
on
where
you
know
people
are.
A
You
know
the
benchmarking
working
group,
you
know,
manages
obsessively
the
benchmarking,
but
you
know
it
manages
it
internally,
with
a
suite
of
you,
know,
applications
and
and
tests
that
you
know
we're
designing
and
we're
running
against
our
stuff.
You
know
my
takeaway
from
from
you
know.
Achmed
here
is
there's
an
opportunity
to.
You
know,
extend
that
beyond
our
infrastructure
and
you
bring
in
that
your
the
data,
not
just
the
you
know,
is
the
diagnostic
working
or
are
we
able
to
get
the
data?
But
where
does
that
data
go?
D
So
if
you're
improving
the
tooling,
then
you
have
more
of
an
opportunity
to
people
to
actually
do
that
more
and
then
you
can
surface
more
feedback
in
terms
of
oh
yeah,
this
version
or
dispatch,
or
this
change
is
actually
impacting
my
code.
But
if
I'm
gonna
have
to
do
this
kind
of
profile,
dumping
and
managing
and
then
you
know
filtering
the
data
through
every
single
time,
then
as
a
developer,
I'm,
probably
I'm
gonna,
do
it
I'm
not
gonna.
Have
the
time
yeah.
A
There
are
some
scripts
across
the
other
code
base
right
the
you
know
the
approach
that
you
would
see
in
chrome,
dev
tools
or
you
know
other
infrastructure
like
that-
would
be
that
you'd
phone
home
and
you
know
being
able
to
put
send
transmit
anonymize
data.
You
know
to
to
you
know
some
centralized
location.
Is
there
any
your
latitude
to
explore
that
or
is
that
gonna
be
a
non-starter.
D
It's
possible
I'll
have
to
think
about
it
more
and
perhaps
more
to
find
more
criteria,
but
the
challenge
there
is
also
like
how
effective
is
that
be
because
that's
what
I
asked?
What
do
you
mean
by
large
since
our
units
of
code
are
as
small
as
we
can
make
them?
You
know
micro
services
and
all
that
and
rapidly
changing
and
rapidly
deployed.
You
know
we
deploy
to
production,
I
think
like
close
to
500
600
times
a
day
across
of
our
teams.
D
So
how
can
I
make
that
information
useful
without
it
being
too
noisy
during
due
to
the
you
know,
continuous
upgrades
and
continuous
improvements
and
continuous
deployments
that
happen
again.
That's
one
area
where,
if
you
provide
the
guidance,
the
structure,
then
you
know,
companies
can
take
that
and
say:
ok,
yeah,
you
know,
I
have
a
framework.
I
have
a
playbook
I,
have
the
type
of
information
that
I
can
provide
here?
D
E
Dan
was
asking
in
the
context
of
trying
to
help
the
enterprise
understand
their
performance,
so
I,
it's
almost
not
I,
don't
know
Dan,
maybe
I
miss
mischaracterizing.
It's
not
necessarily
what
we're
looking
for,
but
helping
the
enterprise
get.
What
they're
looking
for
in
terms
of
the
performance
analysis
having.
A
Shared
visibility
into
that
context,
where
we
go
they
go
and
point
to
that.
You
know
in
if
there's
a
data
stream
coming
somewhere,
then
you
know
we
could
collectively
you
know,
go
there
it
just
you
know
trying
to
it's
a
very
common
practice
in
business.
Trying
to
do
that
in
open
source
and
foundation.
Is
you
know
it's
never
seemed
like
the
the
right
approach,
but
I've
always
you
know
wanted
to
keep
testing
that
to
see
you
know
the
the
community
really.
D
D
D
Http
archive.org
is
basically
a
collective
of
mass
amount
of
data
about
HTTP
traffic
around
the
world,
and
people
use
that
as
a
resource
to
look
up
information
and
determine
things
about
how
this
state
of
the
web
platform
is.
So
people
can
go
and
then
say:
oh
I,
wonder
how
many
people
are
using.
You
know
a
synchronous,
scripts
and
the
web
today,
because
that
information
is
logged,
then
you
can
actually
see
it
so
they're
actually
able
to
derive
information
and
data
from
it
and
it's
both
kind
of
crawl
base
as
well
as
people
contribute
to
it.
D
So
I
often
see
it
where
people
go,
and
it's
like,
oh
I,
wonder
how
many
people
are
still
using
this
CSS
property
and
how
many
people
are
actually
doing
kind
of
lazy
loading
of
images.
For
example,
what
is
the
average?
You
know?
Javascript
page
saw
page
size
or
page
weight
per
project
like
there's
interesting
metrics
that
people
are
able
to
derive
again
because
it's
a
public
data
set.
B
A
D
F
A
The
Delta
between
there,
the
concept
of
APM
and
telemetry
telemetry,
is
specifically
an
anonymized
and
yeah
usage
and
so
strips
out
all
the
context
and
APM
is
the
opposite
of
that,
where
you're
trying
to
thread
together.
All
of
the
the
context
into
you
know
a
coherent
view
of
all
the
the
bits
and
pieces.
Okay.
F
D
Another
another
idea
comes
mind
just
as
he
was
talking
about
this,
like
I,
remember
in
Google
Analytics.
Nowadays
you
can
actually
opt
in
to
share
your
data
anonymously
with
the
collective
so
that
people
can
actually
leverage
it
right.
So
it's
part
of
the
Google
index
features
I,
guess
you
could
have
this
conversation
with
kind
of
companies,
let's
say
like
New,
Relic
or
dynaTrace,
or
so
on
of
maybe
that's
a
contribution
they
can
have,
and
then
they
enable
companies
like
ours
to
check
that
box
and
snai
yep
I'm.
Okay,
with
sharing
the
anonymous
data.
That's.
A
A
A
You
know
some
action
items
and
then
you
know
to
this
group,
which
is
you're
going
to
be
on
a
you
know,
a
recurring
basis
here
in
a
user
feedback
yeah
we
have.
We
have
some
great
topics
to
feed
back
into
a
broader
discussion
that
came
out
of
this.
So
I
really
want
to
thank
you
often
for
taking
the
time
today
to
share
that
user
feedback.
You're.
H
A
I
think
that
that
you
know
enabling
you,
since
we're
in
that
you
know
the
the
ten
dot
current
I
I
think
this
is
a
that's
a
great
starting
point
for
the
discussion.
Where
we'll
all
you
know
talk
about
current
talk
about.
We,
oh,
you
know
test
some
of
our
assumptions
around
current
uses
interest
in
in
current,
and
you
know
feed
that
back
in
and
make
sure
that
everyone's
having
a
great
experience,
yeah.
E
And
I
think
I
think
around
the
and
and
what
can
we
sort
of
document
and
recommend
and
ask
that
kind
prices
can
do
and
to
help
validate
the
current
so
that
you
know
the
LTS
is
as
good
as
it
possibly
can
be
because
I
think
that's
I
agree
it's
a
good
time
so
that
that
would
be
I
quite
like
that
is
our
next
topic.
Yeah.
A
Well,
thanks
everybody
for
taking
the
time
for
this
public
user
feedback
around
the
enterprise
use
case
thanks
Ahmed,
and
tell
us
for
sharing
all
the
context
and
tyranny
and
Madison
for
representing
Kham
Kham
and
the
the
TSE
and
Mark
Hinkel
for
joining
us
for
the
foundation
perspective
thanks,
everybody
and
we'll
talk
soon.
Thank
you.
Talk
to
y'all
later
bye.