►
From YouTube: Node.js Foundation Modules Team Meeting 2018-09-12
Description
A
We're
live
on
YouTube,
it
is
the
September
12
2018
modules
team
meeting
for
the
nodejs
project,
we're
joined
with
myself
and
11
other
individuals,
and
we
have
a
jam-packed
agenda
for
today.
Is
there
anyone
on
the
call
who
is
able
to
help
with
notes
today.
A
A
The
first
thing
to
bring
up
is
issue
number
177,
a
session
at
the
collab
summit
in
Vancouver
I,
don't
know
how
many
of
the
people
on
the
call
are
aware,
but
node
plus
just
interactive,
is
coming
up.
It
is
coming
up
in
you
know,
just
a
couple
weeks
and
there's
going
to
be
a
collaborator
summit.
That's
going
on
two
days.
It's
specifically
October.
A
The
event
is
happening.
My
schedule
is
all
over
the
place.
It
is
October
10th
to
12th,
and
the
12th
and
the
13th
are
the
collaborator
summits,
and
we
have
time
on
the
agenda
specifically
to
talk
about
node
and
so
to
talk
about
modules
in
node,
and
so,
if
anyone's
going
to
be
there,
it
will
be
a
great
time
to
collaborate
on
some
of
this
in
person.
For
those
of
you
in
the
group
who
are
not
planning
to
attend
primarily
for
financial
reasons,
we
do
have
a
travel
fund.
A
So
if
you
are
interested
in
finding
out
more
about
the
travel
fund,
please
reach
out
to
me
and
I
can
help
you
figure
out
how
to
get
a
sponsor
trip
to
Vancouver
to
participate
in
the
event,
and
we
also
have
an
ability
for
those
in
the
project
to
get
discounted
tickets
for
zero
dollars
to
the
conference
as
well.
So
please,
you
know
reach
out
to
me
if
this
is
something
that
you're
interested
in
the
next
one
we
wanted.
A
quick
little
update
on
is
creating
terminology.
I
believe
that
Scylla.
C
Yeah
so
I
guess
I
wanted
to
get
the
PR,
so
people
would
start
contributing
to
it.
I
think
you
know
compared
to
most
on
the
team
terminology
is
really
you
know
their
area
where
they
have
terms
to
define
ie
was
very,
very
interested
to
at
least
have
a
definition
for
a
turn,
but
at
this
point
I'm
not
sure
from
my
part,
what
I'm
able
to
to
do
to
move
this
forward.
I'm,
definitely
open
for
recommendations
from
everyone.
C
A
Okay,
excellent,
so
if
people
could
take
that
any
of
the
concerns
or
thoughts
that
they
have
to
the
issue
on
that,
it
would
be
greatly
appreciated.
I
believe,
if
I'm
right
by
looking
at
the
list
of
panelists,
that
we
have
15
people
here,
13
of
which
are
active
members,
which
means
we
have
quorum
so
I
would
like
to
quickly
get
quorum
on
approving
rubies
at
Ruby's
request
to
join
as
an
observer.
Does
anyone
object
to
this
excellent,
and
so
it
is
that
is
considered
past
rubies.
Welcome
to
the
team.
A
C
C
A
A
We've
been
working
on
this
for
six
months,
trying
to
get
things
ready
for
newer
versions
of
node,
and
you
know
node
11
will
be
cut
in
October
and
if
we
want
to
have
any
chance
of
actually
having
stuff
ready
for
node
12
that
could
end
up
in
our
next
LTS.
That
will
be.
You
know
pretty
much
being
managed
until
2022.
A
We
will
need
time
to
do
it.
Eration,
so
I
want
to
make
it
really
really
clear
to
the
group
about
my
intentions
on
that
and
I
know
hard
deadlines
suck,
but
my
time
yeah
I
don't
have
I,
don't
have
time
to
continue
investing
in
something
that
I
don't
feel
will
be
successful
and
I'm
not
saying
that
I've
given
up
right
now,
but
I
am
genuinely
getting
close
and
I'm
sorry
to
share
that
in
a
harsh
way.
But
I
don't
know
how
else
to
say
it.
At
this
point,
I'm
slow.
C
Are
trying
to
work
on
the
survey
process?
Obviously
our
initial
goal
was
the
developer
survey,
but
internal
surveys
is
something
that
everyone
expressed
interest
in
last
meeting
and
based
on
that,
we
tried
to
roll
out
a
survey.
Today
we
had
a
lot
of
people
take
part
which
is
good,
not
everyone
which
would
have
been
a
lot
better,
but
obviously
because
we're
still,
you
know
doing
this
for
the
first
time.
We
can't
really
expect
that
everyone's
aware
that
it's
going
on
and
we
actually
don't
have
some
people's
emails,
so
they
didn't
even
get
invited.
C
So
what
I'm
trying
to
say
is
that
doing
this,
the
old
process
without
trying
to
change
something
is
probably
going
to
be
the
reason
if
this
doesn't
doesn't
work
out.
Let's
try
to
all
come
up
with
different
ways
to
do
things
and
I
think
there's
definitely
a
lot
of
potential
with
everyone
involved
in
the
group,
and
we
all
have
this
as
a
mutual
goal
and
definitely
we're
gonna
turn
this
around
I
have
very
you
know
like
confidence
in
everyone.
E
Jeffrey
yeah,
so
I
have
a
few
thoughts
on
this
one
is
that
I
mean
I've
been
you've
seen
basically,
my
like
main
concern
with
the
existing
implementation.
That's
been
the
whole
yes
mas
thing
that
I've
opened
several
issues
about
and
tried
to
like
drive
a
process
to
reach
a
consensus
first,
that
we
should
do
something
about
this
and
second,
how
should
we
do
something
about
this
and
I
feel
like
we
made
a
lot
of
progress
there,
although
I
feel
like
the
tools
to
do
so
are
poor.
E
Like
the
whole,
it
you
know,
github
issue
or
pull
requests
tools.
Just
don't
seem
to
fit
very
well
into
like
working
for
many
people.
So
if
there
are
better
ways
to
do
that,
I'd
love
to
see
them,
and
then
it's
like
I
got
to
the
point
of
like
okay.
So
let's
make
a
pull
request
and
I
kind
of
coincide
with.
Oh,
let's
start
over
and
do
a
minimal
implementation.
E
And
so
then
it's
like
all
the
attention
is
going
to
the
minimal
implementation
and
so
but
then
I
don't
know
kind
of
how
we're
moving
forward
with
that
too.
I
think
like
what
we
need
is
like
what
we
need
some
direction
in
terms
of
like
who's
supposed
to
be
doing
what,
when
and
terms
of
like,
if
we
were
working
on
the
minimal
application.
E
A
A
What
a
minimal
kernel
is,
and
so
I'm
just
gonna,
read
that
to
everyone
and
then
kind
of
kick
off
a
discussion,
and
then
we
can
maybe
start
a
shared
doc
or
put
that
into
a
comment,
but
so
a
minimal
implementation
we
believe
requires
bear
in
Forte's.
This
is
something
that
we
think
is
necessary
for
either
browsers
or
node
or
any
runtime
that
that
wants
to
have
a
serious
module
implementation
that
will
be
used
with
good
user
experience.
A
We
believe
that
a
minimal
implementation
could
not
have
dynamic
path.
Searching
requiring
a
full
path
is
an
issue
for
tooling,
and
a
long
term
situation
is
required
in
migration.
Strategies
will
have
to
be
discussed
so
to
be
explicit.
One
of
the
stakeholders
that
we
were
talking
about
when
discussing
this
was
very
much
for
the
typescript
use
case
for
the
CoffeeScript
use
case
for
many
of
the
use
cases
where
this
won't
work,
but
we
do
think
that
the
minimal
implementation
cannot
have
it
and
in
Jordan
I
do
see
your
hand.
A
Are
you,
okay,
with
waiting
until
I
finished,
going
over
yep?
All
of
a
sudden?
We
believe
that
not
have
what
was
it.
The
last
part
was
dynamic
path
searching,
so
that
means
explicit
paths
and
I'll
quickly
go
over
how
this
is
implemented
afterwards,
and
perhaps
I
should
just
I'll
copy
paste.
What
I'm
reading
into
into
the
chat,
and
maybe
that
will
help
people
follow
along
better
and
I'll,
just
add
context
while
I'm
reading,
and
it
is
not
letting
me
paste.
A
D
A
Will
figure
that
out
afterwards
and
it
just
quickly
blast
through
this?
It
requires
commonjs
backwards
compatibility,
but
how
that's
done
it
should
likely
be
through
something
like
create,
require
function
which
does
support
this.
Something
like
import
meta
require
is
something
that
can
be
discussed
later
on,
but
should
not
be
part
of
the
initial
kernel,
and
we
should
also
hold
off
on
being
able
to
import
common
j/s,
specifically
until
more
progress
is
made
on
the
diamond
dynamic
module
spec,
which
is
something
that
guy
is
working
on,
that
would
allow
for
named
exports
in
the
middle
implementation.
A
Mjs
should
be
the
only
way
to
currently
import
s/m.
To
be
explicit,
the
intention
is
to
move
forward
with
format,
databases
as
a
way
to
map
extensions,
to
support
multiple
use
cases,
so
Jas
should
be
able
to
be
used
eventually
to
support
lots
of
different
use
cases,
but
that
we
want
to
essentially
not
have
a
set
in
stone
way
to
use
it
to
start
and
that
the
minimal
implementation
would
only
support
importing
ESM.
So
that
would
mean
it
would
not
support
JSON
it
would
not.
Support
native
modules.
A
Create
require
function
can
be
used
to
get
these,
but
that
all
of
these
features
would
be
examined
later,
potentially
through
something
like
a
format,
database
or
other
ways
to
bring
it
in
and
and
that's
kind
of,
the
idea
that
we
have
there
and
one
of
the
big
parts
of
it
is
ensuring
that
that
this
thing
is
able
to
be
used
and
able
to
do
all
possible
use
cases.
So
what
I'm
going
to
do
really
quickly
is
we?
A
We
have
that
issue
on
minimal
issues,
I'm
just
going
to
paste
the
copy
into
it,
and
it's
issue
166,
because
it's
not
letting
me
paste
it
into
the
chat.
I
guess
it's
too
long.
The
suggestions
that
we
have
to
to
move
forward
would
be
three
pull
requests.
One
is
one
that
removes
importing
the
floor,
mats
other
than
ESM,
so
no
command
J
has
no
JSON
their
native
modules.
The
other
is
removing
dynamic
path,
searching
so
no
extension
adding
their
directory
resolution.
A
No
support
for
index.jsp
would
still
support
the
main
field
for
packages
so
that
they
can
be
required
as
a
bare
import
and
adding
the
create
require
function
is
the
belief
and
Brad
signed
off
on
this,
and
I
was
plus
one
on
it,
as
was
guy
that
this
minimal
kernel
is
something
that
allows
all
of
the
use
cases
that
we
have
discussed.
It
is
by
no
means
something
that
we
should
be
directly
shipping,
but
I
think
that
it
is
a
kernel
that
all
of
our
proposals
could
equally
build
on
top
of
without
giving
any
one
proposal.
F
Yeah
I
guess
the
I'm
conflicted
here,
because
I
agree
that
path
searching
can
be
seen
as
a
added
feature
and
therefore
even
you
know,
even
even
if
we
decide
we
want
to
ship
that
by
default
that
we
could
that
that
could
be
argued.
That
path
searching
is
something
built
on
top
of
the
minimal
kernel.
So
I
see
that
argument.
However,
I
don't
see
that
feature
as
something
that
can
ever
not
be
there.
F
So
I
I'm
not
I'm,
not
sure
how
to
resolve
that
to
then
come
up
with
a
like
official
position
for
myself,
but
like
I
I,
wouldn't
I'm.
Not
yet
at
the
point
where
I
want
to
say
it
must
not
be
a
minimal
kernel
unless
it
has
past
searching
but
I
feel
very
uncomfortable
about
shipping.
A
minimal
kernel
without
it
and
I
think
to.
A
A
I
do
I
do
think
it's
worth
considering,
though,
that,
like
that,
the
minimal
kernel
that
we're
discussing
aside
from
CROI
create
require
function,
which
is
something
that
would
throw
in
most
environments,
would,
for
the
most
part,
be
compatible
in
other
environments.
Salaah,
you
had
your
hand
up
yeah.
C
I
think
I
think
what's
missing
in
this
list
is
what
the
minimal
implementation
does
not
close
the
door
on.
In
other
words,
everyone
on
the
team
wants
to
see
a
lot
more
than
what
is
listed
here
and
they
are
going
with
the
assumption
that
it
will
be
possible,
but
they
are
also
now
going
with
a
fear
that,
at
my
not
could
we
add
a
third
bullet
list
with
this
things
that
we
are
committed
to
actually
reaching
I.
C
What
we
are
closing
the
door
on,
maybe
what
we
are
definitely
not
going
to
do?
Can
we
can
we
have
that
list?
We
can
try
to
put
it
together.
Yes,
like
you
know
beyond
minimal
like
like,
when
this
land,
it
will
not
do
the
following
mm-hmm,
you
know
what
I
mean
this
way.
People
know
that
they
are
not
committing
to
something
that
goes
entirely
against
what
they
hope
for.
Okay,.
G
Yeah
I
was
just
going
to
kind
of
back
up,
Jordan,
said
and
say
that
the
men,
a
minimal
implementation
that
isn't
it
isn't
sufficient
by
itself.
You
know
to
meet
anyone's
standards.
It's
kind
of
big.
It
kind
of
just
begs
the
question
of
consensus
to
begin
with,
so
it's
perhaps
it
can
move
us
towards
consensus
and
I
hope
that
it
can,
but
it
may
also
be
that
it
just
you
know,
delays
the
inevitable.
You
know
my
discussion
about
you
know
finding
consists
is
upon
things
that
we
don't
have
consensus
on.
H
Hi
maybe
like
as
a
as
a
middle
ground.
Here
we
have
all
of
these
things
that
are
like.
We
can't
even
find
consensus
to
put
them
in
the
minimal
kernel
and
they're
like
for
the
things
that
are
already
in
there
and
look
in
the
code
base
at
this
moment.
What,
if
we
just
put
them
behind
flags
instead
of
having
to
you,
know,
argue
about
whether
to
remove
them
or
not,
just
like
as
a
as
a
middle
ground
solution,
there.
A
C
A
Think
one
of
the
challenges
that
we
would
have
with
that
Gus
is
at
least
in
my
mind.
One
of
the
intentions
of
the
minimal
kernel
is
to
have
a
shared
code
base
that
every
poll
request
for
a
set
of
features
that
make
a
solid
proposal
can
be
made
against
the
same
codebase
and
if
we
start
having
some
features
that
are
flagged
in
some
features
that
are
not
flagged.
It
makes
things
a
little
Messier
to
do
that.
E
We
pretty
much
had
consensus,
at
least
in
github,
about
the
ESM
and
j/s
thing,
but
that's
pushed
off
as
a
like.
You
know
this.
Isn't
this
isn't
part
of
the
first
pass
of
this
because
it's
not
really
necessary.
You
know
in
the
phase
one
of
the
new
kernel
which
I
agree
with,
but
it's
also
like
you
know.
If
you're
gonna
have
a
list
of
like
features,
we're
gonna
ship
with
I
wouldn't
want
this
to
be
like
alright.
This
is
a
must
ship
with,
must
build
this
before
shipping,
but
can
be
in
a
later
phase.
E
The
new
Colonel
construction
type
of
thing-
maybe
we
can
make
it.
Maybe
we
can
make
a
list.
That's
like
kind
on
to
tracks
of
like
these
are
that
this
is
like
phase
1,
2,
3,
etc
of
the
new
Colonel.
The
things
we
all
have
consensus
on,
but
like
don't
necessarily
have
to
be
in
phase
1,
etc,
and
then
a
separate
list
of
like
things
that
we
don't
have
consensus
on
so
may
or
may
not
be
in
any
phase,
etc.
A
That
sounds
good.
One
thing
I
would
encourage
against,
though
Jeffrey
is
assuming
that,
because
there
was
consensus
and
a
github
issue,
though
we
have
consensus
within
the
team.
Speaking
for
myself,
there
is
so
much
noise
in
the
github
issues
that
I
tend
to
disconnect
from
those
and
more
engage
in
the
meetings
for
what
it's
worth,
but.
E
C
Sorry
to
interrupt,
but
I
think
what
we
tried
to
address
with
the
survey
at
the
internal
survey
is
actually
come
up
with
a
tool
that
can
allow
us
to
move
forward.
Just
imagine
that
this
list
was
basically
based
on
people
responding,
whether
or
not
they
wanted
a
feature
in
the
minimal
or
flag
or
not
at
all
or
never.
You
would
have
everyone's
results.
You're
not
doing
it.
D
Also,
what
I
would
say
is
to
the
flag
solution,
just
as
a
late
PS
to
that
one
I
think
we
don't
have
a
lack
of
alternatives
and
what
we
might
do
and
we
might
not
do
and
if
we
want
to
have
a
shot
at
influencing
what
the
ecosystem
is
doing.
If
you
want
to
have
a
chart
shot
of
actually
making
decisions
ourselves,
we
have
to
make
choices
and
not
create
options,
because
the
webpack
default
behavior
will
not
be.
I
A
I,
don't
think
we
were
ever
saying
like
I
mean
perhaps
there's
a
misconception
here.
This
is
about
work
that
we're
doing
on
the
fork.
This
isn't
about
anything
that
we're
shipping
in
node
core
or
anything
that's
going
in
a
release.
This
is
solely
about
creating
a
common
ground,
reaching
consensus
on
something
so
that
we
can
have
a
win
and
have
a
shared
kernel
that
we
all
agree
are
features
that
need
to
exist
and
that
all
of
what
we're
trying
to
build
can
be
built
on
top
of
Sola.
A
Without
a
hand-up,
I'll
again
speak
to
that,
so
I
think
that
the
challenge
here
in
perhaps
this
is
something
that
we
can
attempt
to
reach
consensus
on.
I,
don't
think
it's
about
what
feature
we
want
on
and
off.
I
think
it's
about
what
collection
of
features
make
a
proposal.
That
is
a
fully
thought-out
user
experience
and
it's
not
solved
by
turning
on
one
thing
or
turning
off
another
thing,
because
they
are
all
interconnected
and
there
is
a
combinatorial
complexity
of
how
these
interact
with
one
another
yeah.
C
Could
I,
just
after
that
I
do
understand
that
this
is
ultimately
the
goal,
but
to
build
towards
that
goal.
You
have
to
start
not
considering
every
single
thing,
every
single
aspect
of
the
user
experience,
because
that
all
means
this
list
is
obviously
not
that
by
anyone's
perspective
right.
So
so
everyone
compromises
a
lot
to
say
that
this
is
a
good
user
spirits.
C
So
as
a
starting
point,
whatever
features
some
might
not
be
happy
with,
should
be
considered
as
a
potential
feature,
not
a
feature
that
is
on
by
default.
The
minimal
implementation,
in
my
mind,
is
an
important
CSM,
and
if,
if
it's
doing
anything
that
is
beyond
the
module
rap,
then
it
is
depending
on
note
and
then
this
is
a
choice.
J
J
A
E
Was
just
gonna
say,
I
mean
we
obviously
have
at
least
a
few
things
that
are
certainly
we
all
agree
on
like
the
minimal
implementation
should
import
you,
SAP,
etc.
I
don't
know
if
this
is
already
in
the
minimal
Fork,
that's
out
there
but
like
if
we
have
a
few
tasks
that
are
already
like
there
and
someone
just
needs
to
go
and
do
them,
you
know,
can
we
start
organizing
that
or
maybe
not
in
this
meeting
but
like
just
to
start
getting
the
wheels
turning
and
making
forward
progress.
A
For
for
what
it's
worth,
Jeff
I,
as
far
as
I
am
concerned,
we
have
all
of
the
code
already
written
to
have
this
minimal
kernel
ready
to
go
tomorrow.
It
just
needs
to
be
collected.
Gus
is
create,
require
function,
ready
to
go
aside
from
not
having
consensus
over
on
the
main
repo,
but
like
is
the
PR
ready
to
kind
of
maybe
be
transitioned.
H
Over
it
needs
to
be
rebased,
but
beyond
that,
it's
fine
and
I
would
say
one
thing,
as
you
says,
outside
of
esm,
which
is
why
I
put
it
against,
which
is,
which
is
why
I
didn't
move
it
over
to
the
icon
script
repo,
but
you
know
feel
free
to
review
it
now.
I
just
have
to
resolve
of
merge
conflict
on
it.
Okay
and.
A
A
What
we're
doing,
no
so
the
the
intent
of
stating
this
was
that
we
do
have
a
moratorium
on
modules
and
because
this
affects
modules
it
would
in
theory,
you
know,
be
something
that
we
would
want
to
have
buy-in
from
the
from
the
group
on
so
I
was
thinking
you
know.
Obviously
it
would
still
need
to
go
through
the
node
process
and
anyone
from
the
project
could
object
to
landing
it.
A
But
if
we're
thinking
about
landing
it
at
our
minimal
kernel,
if
we
have
consensus
of
that
being
part
of
our
minimal
kernel,
then
it
seems
reasonable
that
we
would
that
we
would
make
a
recommendation
for
node
core
to
consider
landing
it
in
in
core
and
Benjamin
to
your
to
your
question.
Require
can
be
built
on
top
of
create,
require
function
while
landed
in
core
and
not
just
into
our
four,
because
it's
a
generally
useful
function
as
Wes
was
saying
that
should
likely
be
in
core
anyways
and
I.
A
C
Yeah
so
I
think
on
top
of
create
required
function.
You
should
have
sort
of
a
list
of
this
kind
of
contribution,
something
that
the
community
needs
anyways
and
could
help
us,
but
also
to
clarify
whether
or
not
this
is
you
know
the
only
direction
we're
going
to
be
taking
would
be
important
at
this
point.
A
So,
based
on
that,
and
as
we
have
quorum
in
the
group
with
no
objections,
I'm
gonna
make
that
recommendation
and
Jeremiah.
If
you
have
concerns
in
review
as
a
collaborator
on
the
project,
I
encourage
you
to
you
know,
do
what's
necessary
in
in
that
pull
request
based
on
the
review.
Does
that
seem
reasonable
to
you.
A
Cool
I
just
want
to
make
sure
that
we're
communicating
properly
you're.
Okay
with
that,
so
we've
gone
through
the
twenty
minutes
and
I
want
to
make
sure.
That's
a
lot
has
time
to
review
all
of
this
stuff
with
with
the
survey
with
us.
I
would
really
appreciate
for
those
of
you
who
have
been
on
the
call
who
have
concerns
about
the
minimal
kernel.
A
You
know,
I
know
Jordan,
and
a
few
of
you
have
expressed
Kevin
had
to
drop
it
expressed
issues
potentially
with
the
past
searching.
If
you
could
go
into
the
issue,
what
I
would
find
personally
most
productive
if
you
could
make
alternative
proposals
or
specifically
talk
about
not
just
the
thing
that
you
have
problems
with,
but
explicit
alternative
things
that
we
could
do.
A
I
would
really
love
to
see
if
we
could
reach
some
sort
of
consensus
around
this
I
may
take
an
action
I'm,
actually
putting
together
a
pull
request
to
implement
what
is
said
in
that
minimal
kernel.
So
if
people
have
hard
objections,
if
you
could
get
those
in
you
know
in
the
next
day
or
so,
I'd
really
appreciate
it
so
law
I'm
gonna
hand
it
off
to
you
to
lead
the
discussion
on
the
survey.
C
A
C
C
Yeah,
so
I
guess
you
know
if
you
can
write
all
that
long
arrow,
that's
fine,
but
I,
think
the
idea
of
an
internal
survey
is
that
it
really
helps
people
who
are
either
not
able
to
participate
in
ongoing
discussions
for
reasons
that
there's
too
much
noise
or
otherwise,
and
especially
those
who
cannot
contribute
to
the
meeting
or
take
part
in
the
meeting
discussions.
Those
surveys
are
a
really
good
tool.
If
someone
wants
to
propose
something
and
have
everyone,
you
know
give
their
opinion
on
it.
C
C
And
consensus
really
is,
you
know
not
possible
if
you
can't
have
everyone
going
through
the
same
path
to
indicate
what
they
really
feel
about
something
the
way
questions
are
phrased
is
not
going
to
be
really
the
topic
of
this
conversation,
because
a
few
people
took
the
initiative.
They've
done,
in
my
opinion,
amazing
work
and
anyone
who
would
like
to
improve
upon
this
survey
or
any
kind
of
survey
effort.
We
are
doing
we're
a
collective
effort.
This
is
our
effort
together.
C
So
with
that
said,
I
will
have
to
say
I
didn't
write
those
dresses,
no
no
I
was
actually
part
of
the
group,
but
other
people
really
did
a
far
better
job
than
my
own
drafts,
which
you
will
get
to
see
too.
So
it's
not
really
a
good.
You
know
indicator
that
we
only
have
10
responses,
so
these
results
can
be
any
kind
of
results.
C
It
doesn't
matter
at
this
point,
so
we
don't
take
a
lot
out
of
whether
or
not
decisions
can
be
made
from
this,
but
I
think
the
most
important
thing
we
can
get
from
this
is
that
we
need
tools.
This
could
be
a
tool
that
we
can
all
learn
how
to
use
to
reach
the
consensus
that
we
all
need
so,
based
on
this,
we
have
to
ongoing
tracks
the
B
track.
C
It's
basically
the
internal
surveys
they're
intended
to
help
us
with
our
internal
processes
the
C
track,
which
is
based
on
what
we
did
in
the
first
set
of
you
know.
Private
iterative
reviews
is
going
to
be
this
team,
like
in
general,
the
workgroups
effort,
collective
effort
to
create
a
survey
that
will
be
for
developers
and
you
know
by
next
month.
Let's
put
it
this
way.
How
it's
going
to
be
rolled
out
is
not
yet
determined,
but
we
want
to
have
it
maybe
in
the
collab
sessions.
That
would
be
a
really
good
starting
point.
I
Right
so
I've
been
looking
over
the
questions
like
this
is
the
one
thing
that
I
don't
understand
from
them.
I
gather
they're
telling
me
new
things,
and
they
have
responses
for
like
do.
We
know
like
what
the
derived
action
items
are
from
these
questions
is
based
on
like
what
we
see.
The
responses
are
like
what
kind
of
things
we
want
to
pursue,
based
on
the
responses
to
each
of
these
questions.
C
It's
it's
what
we
will
get
from
the
survey
that
we
deploy
the
developer
survey,
it's
the
direction
that
surveys
should
take.
Generally,
we
are
getting
there
it's
just.
There
was
no
process
to
create
a
survey.
We
did
what
we
felt
was
important
to
actually
get
into
the
process
begin.
The
process
and
everyone
who
has
a
concern,
should
work
with
other
people
who
can
eventually
get
a
good
question
onto
a
survey
that
goes
public.
C
Everyone
that
has
a
concern
within
the
group
should
work
with
others
to
try
to
come
up
with
a
good
question
to
have
their
concern
addressed
within
the
group.
It
doesn't
work
that
you
know
two
three
people
sit
and
do
this
for
the
group.
The
group
has
to
do
that
collectively.
It
has
to
be
driven
by
your
incentive
to
get
an
answer.
C
People
can
be
good
at
working
with
you
to
do
that.
So
we
have
people
who
you
know
did
that
for
the
past
couple
of
weeks,
but
obviously
people
who
have
good
questions
didn't
like
the
questions
that
they
saw
and
and
I
guess
that
can
apply
to
everyone.
C
I
Hand
up
again
well,
not
quite
it
was
more
technical
like
based
on
the
feedbag,
for
like
the
first
question
like
for
the
question,
you
have
one
screen
right
now
or
how
will
no
js'
users
find
import
metadata
useful,
like
what
is
the
planned
response
based
on
how
that
question
is
responded
to
like
if
everyone
responds
they
won't
use
it
at
all
for
no
js'
programs.
What's
our
expected
response,
if
everyone
responds
see,
I
still
find
use
it
as
frequently
as
dare
name
or
file
name?
C
C
It's
a
good
question
from
my
perspective,
what
it
really
delivers
to
us
and
what
it
tells
us
to
do
is
really
something
that
this
group
should.
You
know,
should
figure
out
what
questions
to
ask
developers
at
large
and
to
do
that.
A
starting
point
is
someone
puts
a
question
that
they
think
is
doing
that
and
then
you
come
in
and
suggest
okay,
so
we
need
to
figure
out
exactly
what
we're
trying
to
ask.
That's
a
really
good,
second
step.
So,
okay,
now
we
have
an
idea
of.
C
If
we
want
to
write
a
good
question,
we
have
to
write
out
what
the
question
will
really
be
answering.
So
everyone
has
to
you
know,
refine
the
process
we
move
forward.
So
I
guess
from
answer
is
that
it's
too
early
to
try
to
answer
the
concern
that
you
have,
but
you
know,
let's
make
draft
2
of
this
question
together
and
you
can
help
us
with
your
you
know.
Would
you
know
help
us?
C
C
A
A
So
it's
way
more
useful
as
to
try
to
figure
out
what
kind
of
things
do
people
prioritize
and
what
kind
of
things
do
they
want
us
to
prioritize
and
I
think
to
Wes's
point:
it's
going
to
be
extremely
important
that
we're
intentional
about
what
are
we
trying
to
ask?
What
are
the
answers
that
we're
trying
to
get
and
what
are
we
planning
to
do
with
those
answers
once
we
have
them,
and
I
would
like
to
advise
you
to
not
consider
the
survey
a
form
of
consensus?
It's
not.
A
C
C
It's
one
of
the
tools
that,
if
used
right,
can
actually
reflect
consensus
at
to
a
certain
degree,
but
using
it
right.
It's
something
that
we
all
have
to.
You
know
build
build
a
process
to
guarantee.
You
know
you
can't
have
a
survey
and
then
also
at
the
same
time,
be
talking
about
the
survey
where
other
people
still
didn't
have
it,
for
instance.
So
so
so
we're
all
going
to
learn
from
this
and
and
we're
all
going
to
refine
our
expectations
from
it.
But
it
definitely
is
a
tool
that
you
know
we
can.
C
C
An
ongoing
draft-
it's
not
ready
yet
to
be
sure
that
we're
still
revising
the
ongoing
draft
for
c1,
but
so
so
you
know
it's
a
completely
separate
survey
at
this
point.
I'm,
not
sure
if
you
guys
are
seeing
the
same
window,
yeah
yeah,
so
so
for
that
survey
we
start
off
by
trying
to
understand
who's.
Taking
the
survey
again,
you
know
please
contribute
to
the
process
to
improve
it.
You
know
at
this
point,
comments
are
good,
but
involvement
is
a
lot
more
encouraging
and
a
lot
more
needed
at
this
point.
C
So
we're
trying
to
actually
get
your
input
after
every
question
or
at
the
end
of
every
section.
Then
we
try
to
talk
about
what
you
use
a
note
for
for
for
someone
for
a
developer
who
uses
note
they
can
be,
you
know
using
it
for
a
lot
of
different
things.
We
try
to
get
a
good
snapshot
of
what
they
use
it
for
to
try
to
understand
what
modules
really
mean
to
them.
Again,
there
are
other
drafts.
This
is
not
the
one
draft,
and
so
here
we
try
to
understand
their
codebase.
C
We
try
to
understand
a
bit
about
their
tooling.
Their
compilation
paths
a
bit
about
the
diversity
of
their
production
code,
and
then
you
know
you
move
from
there
to
trying
to
get
their
expectations
about
features
and,
and
here
features
are.
Obviously
the
wording
is
not
the
point
but
features
here
are
more
of
what
do
you
expect?
Yes,
modules
to
be
alike
when
you
use
them
when
they
land,
not
particular
building
blocks
for
from
the
internal
context?
C
C
C
C
This
is
like
draft
zero
for
the
team,
although
it's
been
through
multiple
iterations
within
a
few
of
us
who
have
been
working
on
this
and
then
there's
a
part,
because
a
lot
of
people
are
not
necessarily
good
a
note,
but
our
front-end
developers,
who
are
very
good
in
JavaScript
or
consider
JavaScript
as
one
of
three
things
that
you
know
how
to
do
and
by
front
and
an
optional
section.
That
is
only
given
to
those
who
indicate
that
they
really
are
front-end
developers.
C
A
C
A
C
I
was
hoping
after
b1,
we
would
know
which
areas
of
the
survey
each
one
of
us
is
willing
to
take
part
in
helping
with,
and
then
people
with
matching
interest
will
you
know,
get
together
some
way,
they'll
figure
it
out
and
we
can
begin
a
process.
You
know
we
have
a
checklist
for
all
the
different
areas
that
need
to
be
worked
on
and
those
people
updating.