►
From YouTube: Node.js Foundation Modules Team Meeting
Description
A
A
I'll
just
quickly
name
people
and
if
you
could
just
say
your
name
and
a
brief
reason
why
you're
interested
in
modules
that
may
set
the
you
know,
set
the
tone
really
quickly
as
to
what
we're
doing
so
I'm
miles,
I'm,
really
interested
in
node,
Wed,
Wed
interoperability
and
making
sure
that
modules
that
are
written
using
no
specific
syntax
for
a
runtime
can
run
in
both
environments.
The
next
person
on
my
list,
I,
have
is
Benjamin
Grimm,
Baum,
hi.
B
C
D
Hello,
oh
okay,
good
so
I'm
with
the
typescript
team
and
I'll
be
responsible
for
implementing
typescript
support,
for
whatever
node
does
for
yes
modules
in
the
end
anyway.
So
I
have
a
vested
interest
in
seeing
it
happen
in
a
way
that
makes
it
somewhat
easy
for
transpilers
to
let
these
systems
interoperate.
E
G
I
I'm
guilty
era:
I
wrote
some
articles
on
Honea,
smuggles,
I'm,
really
interested
I
met
Anna
miles
in
Japan
and
got
invited.
My
main
interest
is
is
is
in
trouble
ability
with
browsers
my
dream
is
you
know,
npm
install
and
then
f5
in
the
browser
that
should,
from
my
point
of
view,
just
work.
How
not
sure.
J
Hi
everyone,
yeah
I've,
been
probably
thinking
about
modules
for
a
little
bit
too
long,
I
started
work
on
a
modulator
called
System
jeaious
back
in
2013
for
loading
modules
in
the
browser,
as
along
with
the
package
manager,
trying
to
consider
how
you
could
load
modules
in
the
browser
as
an
alternative
to
the
way
that
we
were
thinking
about
modules
back
in
2013.
So
with
the
dynamic
module
loading
as
the
first-class
feature,
and
that
was
a
package
manager
called
JSP
M,
which
I'm
currently
seeing.
J
K
L
Jd
I'm
a
p.m.
at
Microsoft
working
on
web
apps
and
frameworks
I'm
interested
in
modules,
because
I'm
also
the
creator
of
low
the
most
used
NPM
package
in
the
new
ecosystem
and
I'm
transitioning
to
ES
modules
and
I'm.
Trying
to
cover
the
cases
for
other
devs
wanting
to
switch
to
ES
modules
as
well
and
make
a
smooth
and
seamless
compat
and
integration.
M
Hey
I'm
Lynn
Clark
I
work
at
Mozilla.
You
may
know
me
from
doing
coke
cartoons,
but
the
reason
I
mention
modules
is
because
I'm
working
with
the
web
assembly
folks
to
make
right
now
there's
a
jsapi
for
creating
web
assembly
modules.
We
want
you
just
to
be
able
to
use
web
assembly
as
yes
modules
as
well,
so
working
on
specifying
that
and
also
very
interested
in
interoperability
between
browsers
and
node.
N
O
Q
R
The
senior
muted
sorry,
sir
hi,
my
name
is
Waseem
I'm,
a
JavaScript
developer
from
Paris,
France
and
I'm.
This
is
my
first
contribution
to
the
nerd
foundation
and
I'm
here
like
to
learn
more
about
the
the
model
process
in
architecture
and
more
precise
level.
They
interrupt
between
node
and
the
browser
and
I'm
also
here
like
to
represent
the
web
dev
community.
T
Dead
yeah,
my
name
is
Zack
Schuster
I
work.
As
a
excuse
me,
full
stack
developer
for
company
called
cedar
systems
out
of
California.
We
worked
mainly
in
education
I'm
here,
because
I
want
to
learn
more
about
contributing
to
working
groups
and
being
bigger
part
of
development,
community
and
I'm,
now
learning
more
basically
about
especially
node,
because
I'm
really
been
in
no
developments
hard
for
the
past
few
years,
so
I'm
hoping
that
I
can
contribute,
but
I'm
expecting
more
to
be
learning
than
anything
else.
Amazing.
A
Thank
you
so
excuse
me
hanging
on
you
know,
leave
it
to
the
floor
for
a
second.
Is
there,
anyone
who
didn't
get
introduced.
I
was
doing
my
best
to
go
through
this
list,
but
it
does
not
really
pair
well
if
I
missed
anyone.
Sorry
I'm
just
gonna,
leave
it
to
the
floor
for
a
minute
in
case
I
missed
anyone.
A
Okay,
assuming
I'm
saying
so
Jeremiah,
is
on
the
call
that
his
connection
is
awful,
so
I'll
quickly
introduce
from
Jeremiah
is
another
technical
steering
committee
member
he's
been
around
since
I.
Oh
he's
been
heavily
involved
in
her
modules
implementation,
since
the
beginning,
I
would
say
he's
involved
because
he
has
a
vested
interest
in
making
sure
that
this
stuff
is
successful,
but
I
don't
have
I'm,
not
Jeremiah.
I
can't
totally
do
from
another
thing:
we
have
a
Daniel
who
is
on
right
now,
Daniel.
Did
you
introduce
yourself.
U
A
Awesome
so
if
that
being
said,
thank
you,
everyone
I
feel
like
we
just
went
through
what
will
be
the
first
15
minutes
of
the
next
Avengers
movie.
It's
like
really
cool,
seeing
all
the
people
that
we
have
coming
from
different
parts
of
the
world
working
on
different
projects
and
with
different
insight.
It
will
be
a
unique
challenge
to
make
sure
that
we
can
remain
productive
and
move
things
forward,
but
I'm
feeling
personally
up
to
that
challenge
and
excited
to
collaborate
with
all
of
you.
A
So
if
you
have
the
agenda
document
open,
the
link
I
will
put
one
more
time
into
the
chat.
If
you
have
not
put
yourself
in
there
yet
as
present,
please
do
so.
We
have
a
number
of
different
agenda
items.
Today
we
have
an
initial
goals
document
I'm,
going
to
punt
that
to
a
little
bit
later.
That
is
something
that
we
have
a
pull
request.
That's
been
open
by
Brad.
We
have.
We
have
an
issue
about
the
scope
of
the
team.
We
have
an
issue
about
managing
signal-to-noise.
A
We
have
an
issue
about
the
guiding
the
design
principles
of
our
document.
We
have
an
issue
about
potentially
doing
an
online
module
summit
if
you
on
governance
and
membership
requires
and
requirements
and
another
issue
about
how
often
and
when
we
should
meet
so
I-
think
that
I'm
gonna
put
how
often
and
when
should
we
meet
first.
A
Looking
at
this,
if
you
open
its
issue
number
two
on
the
tracker
I
suggested
a
biweekly
meeting
as
cadence.
To
start,
we
did
an
initial
doodle
poll
which
had
a
whole
bunch
of
people
answer
a
bunch
of
different
things.
I
scoped
that
down
to
ten
potential
times,
you
can
see
a
link
for
the
new
doodle
in
there.
A
At
the
current
moment,
we
have
26
participants
in
the
noodle
if
you
have
not
filled
out
the
doodle,
yet
it
was
mentioned
in
the
issue
that
we
are
explicitly
going
to
be
moving
people
who
do
not
fill
out
that
doodle
to
an
observer
status.
We
have
over
40
people
in
the
group
right
now,
and
this
seemed
like
a
first
good
participation
guideline.
A
If
you're
not
going
to
participate
in
letting
us
know,
when
you're
available,
that
seemed
like
a
good
line,
I
will
be
attempting
to
do
an
email
out
to
everyone
end
of
day
today,
as
an
action
item.
Actually
before
we
start
going
too
far,
can
anyone
volunteer
to
take
notes?
This
is
in
markdown
format.
You
just
write
it
in
line
so,
like
you
know,
we
could
do
a
long
term.
Okay,
awesome,
so
Thank,
You
Zack.
If
that
was
you
who
said
it?
Yes,.
T
A
So
if
we
could
take
a
note,
just
you
know
saying
we
have
the
doodle,
maybe
a
link
to
the
doodle
and
that
people
have
until
Friday
to
fill
it
out
and
an
action
item
for
me
to
email
people
to
make
sure
that
they
see
it
because
we
can
easily
lose
stuff
in
github
noise.
If
you
take
a
look
at
that
doodle
right
now,
you
will
notice
that
we
have
some
times
that
are
really
highly
voted
right
now,
one
being
Monday
at
3:00
p.m.
and
the
other
being
Wednesday
at
4:00
p.m.
A
those
both
have
23
participants
who
are
open
to
using
it.
So
you
know,
leave
it
to
the
floor
really
quickly
and
the
questions
around
this
are
a
does
the
bi-weekly
cadence
work
for
you,
or
do
you
think
that
that's
too
often
or
not,
often
enough
and
then
the
second
one
to
the
floor
is
which
should
we
have
a
single
time
for
these
bi-weekly
meetings
or
a
rotating
time?
A
B
O
A
Added
to
the
official
note
calendar
once
we
have
that
set
up
we'll
have
a
rotating
meeting
and
maybe
after
a
month
or
two
we
can
revisit
and
see
if
the
meeting
time
isn't
working,
we
could
also
potentially
keep
this
issue
open
as
an
ongoing
thing
for
us
to
just
discuss,
but
I
think
maybe
it
doesn't
make
sense
to
bring
up
in
the
next
meeting.
So
with
that
being
said,
we
can
move
to
the
next
item,
which
is
scope
of
the
team
issue
number
17.
A
So
this
is
partially
around
governance,
and
you
know
if
we
plan
to
charter
part
of
the
process
we'll
be
deciding
on
the
scope
of
the
team
and
what
we're
explicitly
asking
for
responsibility
of
the
original
scope
of
the
group
is
ESM,
but
part
of
the
CGS
implementation
may
become
part
of
our
scope
as
well.
I
think
that
this
is
something
we
don't
need
to
dive
too
deeply
into
in
this
meeting.
This
is
more
to
get
it
on
people's
radar.
A
Chartering
is
something
that
comes
later
on
down
the
line,
but
for
those
who
are
who
are
new
to
note
when
we
charter
working
groups,
those
working
groups
are
responsible
for
them
that
part
of
the
code
base
and
that
part
of
our
infrastructure.
If
it's
something
like
the
building
group,
the
TSE
is
often
involved
afterwards.
So
if
there's
conflict
around,
you
know
those
those
particular
decisions.
A
My
hunch
and
original
thought
was
that
we
shouldn't,
because
it
could
create
scope
creep
and
create
extra
responsibilities
for
us
that
CGS
required
implementation
has
been
around
for
a
long
time
and
has
a
lot
of
edge
cases
and
a
lot
of
technical
debt
and
I.
Don't
know
if
that's
something
that
our
team
would
want
to
take
responsibility
for
Jay
Dalton's
question
that
he
has
right
now
about
a
separate
group.
I
think
right
now
that
separate
group
is
the
general
collaborators
there's
no
reason
that
we
can't
participate.
A
We
have
a
lot
of
collaborators
in
the
group,
but
I
can
leave
it
to
the
floor
also.
So
you
all
know
there
is
a
feature
inside
of
this
program,
raise
your
hand,
and
so
if
people
are
talking,
you
want
to
make
sure
you
get
a
word
in
I
will
be
keeping
my
eyes
on
people
who
have
their
hands
raised
to
make
sure
that
they
get
their
points
in
so
I'll.
Leave
it
to
the
floor
for
a
quick
discussion
on
this.
F
So
I
can
just
have
a
comment.
I,
don't
think
we
can
entirely
remove
some
cross-pollination
between
systems,
so
there
there
definitely
needs
to
be
a
scope
of
what
amount
of
CGS
we
are
particularly
taking
on.
In
particular,
we
just
had
pr's
about
package.json
and
the
main
caches,
and
we
might
have
more
package.json
data
coming
in,
which
would
be
in
sync
between
the
two
modules
systems.
I
think
we're
going
to
have
to
take
that
on.
If
we
want
it
to
actually
be
a
cash
that
works
in
both
right
now.
J
J
Sorry,
can
everyone
hear
me
all
right:
it's
okay,
yeah,
basically
I'd
cash
into
the
es
modulator
in
node,
and
we
want
to
share
that
cash
with
a
common,
yes
modulator,
because
it
has
a
cache
of
the
means
so
I
think
that's
what
Bradley
is
referring
to
and
there's
also
been
some
changes
on
that
so
that
there
are
some
crossovers.
But
it's
really
important
that,
obviously
that
we
don't
break
common
tests
so
being
really
wary
at
that
and
drawing
that
line.
J
G
Wanted
to
pick
up
what
guy
just
said,
we
should
scope
ourselves
to
not
changing
the
behavior
of
existing
code.
Perhaps
scoping
this
from
a
user
visible
perspective
might
be
the
way
to
do
it.
This
team
should
avoid
making
changes
that
would
require
work
from
any
existing
users
of
CJ
s
code,
but
behind
the
scenes
things
as
required
by
technical
work,
we're
doing
for
ESM
should
be
fair
game.
F
A
Excellent,
that's
a
really
good
point,
and
maybe
that's
something
that
we
can
add
to
like
our
general
document.
If
we
had
anything
about
scope
to
it,
so
next
up
we've
got
managing
signal-to-noise.
This
is,
if
you
15,
take
a
look
at
it.
I
open
this
issue.
It
was
mostly
around
you
know.
There
was
a
flurry
of
activity
when
we
first
started.
I
think
it
goes
without
saying.
We
have
a
lot
that
we
want
to
talk
about
and
there's
a
lot
of
things
that
we
need
to
talk
about.
A
So
what
I?
What
I've
done
is
a
first
pass
at
trying
to
solve
this
and
I'm
not
sure
if
it
really
helps,
and
if
you
look
at
issue
number
24
labeling
issues
and
PRS
I'll
put
a
link
into
the
chat
for
people.
I
created
a
bunch
of
labels
and
one
of
the
labels
that
I
created
was
a
discussion
label
and
essentially
the
discussion
label
explicitly
means
that
that
issue
is
open
for
general
discussion
and
without
the
discussion
label
the
conversation
is
assumed
to
be
very
scoped.
A
My
hope
would
be
that
the
original
poster
of
the
issue
or
pull
request
would
request
people
to
scope
the
discussion
if
it
moves
outside
of
the
scope
unless
the
rushon
tag
has
had
it.
So
this
puts
an
onus
on
to
people
who
are
opening
issues
and
pull
requests
to
you
know
make
that
request,
which
people
may
not
be
comfortable
with.
So
this
is
an
attempt
I'd
like
to
leave
it
to
the
floor,
to
make
comments
on
those
attempts,
or
you
know,
suggest
other
things,
John
JT.
A
A
A
A
How
things
usually
work
in
the
project
is,
if
you
open
a
pull
request-
and
that
has
you
know
more
than
one
sign
off
on
it
or
sometimes
even
one
sign
off,
and
it's
been
open
for
at
least
48
hours
during
the
week
or
72
hours
during
the
weekend.
If
there
are
no
objections,
that's
that
that
that
it
lands.
If
there
are
objections,
then
that
kind
of
gets
raised
to
the
committee
to
the
steering
committee
to
see
if
this
during
committee
and
reach
consensus
can't
be
reached
in
the
issue.
A
I
think
for
as
we're
kicking
things
off,
we
can
avoid
keeping
things
to
the
TSC
as
much
as
possible,
but
that
may
end
up
happening
requests,
though
we
do
have
the
opportunity
to
design
our
own
governance
model
if
we
want
to
do
something
different,
whereas
regarding
the
decision-making
model,
though
I
guess,
I
can
open
the
floor
first
to
discussing
the
decision-making
model.
Specifically,
the
question
of
like
are
people
okay
with
the
status
quo
right
now,
or
would
anyone
like
to
take
an
action
item
of
writing
an
alternate
model
we're
proposing
an
alternate
model.
A
Okay,
so
based
on
based
on
the
violence,
Oh
Jeremiah
has
a
point,
I
think
sign
offs,
don't
need
to
be
the
same.
We
probably
won't
be
committing
as
much
other
than
core
I.
Think
that's
interesting
I
mean
if
people
are
open
to
it.
Right
now,
like
we
have
a
large
group,
if
pull
requests
have
sign
offs
and
the
sign
offs
and
there's
no
minus
ones,
I
think
that's
a
reasonable
enough
way
to
move
things
forward.
A
A
A
R
A
P
P
A
Though
so,
potentially,
what
we
could
do,
because
we
need
time
to
discuss-
and
we
don't
have
like
such
a
huge
like
fire
to
get
this
done
in
like
a
couple
days,
would
would
maybe
an
alternative
to
that
being
that
we
have
to
reach
quorum
in
a
meeting
tool
and
pull
requests
that
way,
it's
still
kind
of
tacit
approval,
but
there's
two
weeks
there's
a
lot
of
time
and
I
think
this
plays
nicely
into
the
next
question
which
was
having
to
do
it.
Managing
engagement.
P
Yeah
and
actually
like
pull
requests,
are
like
the
thing,
I'm
least
concerned
about
in
some
ways,
because,
like
the
actual
I
am
large,
I
trust
people
to
write
code
is,
you
know,
well
we're
all
pretty
good
at
that
part
and
the
points
of
conflict
that
isn't
where
our
points
of
conflict
are.
That's
what
it
comes
down
to
like
the
stuff
that
we
need
to
hash
through
and
and
come
to
consensus
on
are
unlikely
to
be
code
changes,
except
where
those
code
changes
are
implementing
a
policy
that
we
haven't.
Yet
all.
W
A
Excellent,
so
as
our
first
order
of
business
kind
of
recursively
iterating
on
this
process,
before
it's
even
happened,
do
we
have
quorum
within
this
that
we
want
pull
requests
to
only
land
in
the
modules
repo
that
have
been
that
have
had
quorum
reached
within
a
meeting
yeah?
How
do
we
have
any
objectors
to
that.
A
Is
the
case
with
that
being
said:
Gil
we
can
iterate
on
this
process
at
any
time
and
so
I
think
to
Jeremiah's
point.
If
this
seems
to
slow
us
down,
then
then
we
can
iterate
and
for
context.
It's
only
PRS
against
the
modules,
repo,
ok
cool.
So
would
anyone
like
to
take
two
take
the
action
item
of
documenting
this
in
the
repo
I.
A
F
A
The
two
like
and
Rebecca
correct
me:
if
you
don't
appreciate
this
but
tacit
approval
of
quorum.
You
know
combination
of
in
the
in
the
pull
request
and
within
the
meeting.
If
we
have
no
dissenters,
then
we
move
forward
seems
like
the
simpler
thing.
Alternatively,
we
could
reach
a
quorum
within
the
meeting
with
dissenters,
but
but
I
would
prefer
to
start
to
keep
closer
to
the
process
that
we
already
have
and
then
iterate.
If
we
find
that
that
process
is
blocking
us,
yeah.
P
So
a
quorum
would
really
just
mean
that,
like
if
we
have
one
of
these
meetings
and
only
four
people
show
up,
then
they
don't
get
to
decide
everything
that
it
has
nothing
to
do.
You
know
it.
It's
still
a
consensus
model
amongst
people
who
choose
to
be
present
but
I'm,
fine
with
saying
that
it's
it's
based
on
passive
approval
within
the
meeting
itself.
So
if
nobody
dissents
within
the
meeting
itself,
yeah
I
think
that's
that
I
feel
much
more
comfortable
about
that
excellent.
A
And
then
I
would
I
would
say
quorum.
Rules
for
the
meeting
based
on
our
other
meetings
is
a
quorum,
is
50
percent
of
the
working
group,
okay,
excellent.
So
as
an
action
item
moving
forward
that
I'll
just
state
this
one
more
time
we
are
going
to
introduce
in
small
aware
by
pull
requests
in
the
module
repo
will
only
land
if
there
is
tacit
approval
in
both
the
pull
request
and
a
meeting
that
has
quorum
and
quorum
is
defined
as
50%
of
the
active
members
of
the
group.
A
Once
again,
I
will
mention
that
we
have
21
people
on
the
call
right
now,
which
is
actually
really
close
to
us
having
quorum
based
on
the
group,
but
that
people
who
have
not
participated
in
this
meeting
and
have
not
filled
out
the
schedule
will
be
moved
to
observer
status
on
Friday,
and
we
will
take
everything.
That's
happened
in
this
meeting
as
being
binding.
I.
Don't
think
that
that
sounds
unreasonable.
Alternatively,
I
mean
based
on
our
model
that
we
have
tentatively
agreed
to.
We
would
need
to
have
this
brought
up
in
another
meeting
to
actually
land.
A
U
A
Of
the
team
itself
so
right
now
the
team
is
44
people.
My
estimate
is
that
we
will
move
between
probably
26
and
35
people,
once
some
of
the
people
get
moved
to
observer
status
on
Friday
and
it
would
be
50
percent
of
the
team
members
being
present
in
a
meeting
and
if
we
we
have
problems
reaching
quorum.
This
leads
into
the
next
item
that
we
have
within
this,
which
is
membership
requirements
within
within
the
technical
steering
committee.
B
A
A
So
this
is
more
about
like
can
the
meeting
move
forward
without
quorum
in
the
group
and
should
the
decision
be
made
so
I
think
once
this
is
documented?
Maybe
we
could
kick
this
off
to
the
pull
request
where
we
actually
introduced
this
process,
and
maybe
it
would
be
a
little
bit
clearer
there.
Does
that
answer
your
questions
yeah
excellent?
A
So
so
now
this
does
bring
up
the
question
of
membership
requirements.
So
when
we
require
a
quorum
to
make
decisions,
that
means
that
we
require
require
a
quorum
to
do
things
and
potentially
even
quorum
to
have
meetings.
Gus
just
mentioned
in
the
chat.
We
probably
shouldn't,
cancel
meetings.
It's
a
lot
easier,
easier
to
reach
quorum
with
actual
talking,
so
to
speak
to
that
Gus,
the
quorum
that
we're
talking
about
is
attendance
and
not
necessarily
quorum
as
in
everyone
agreeing
to
something.
A
So
the
idea
would
be
that
if
we
don't
have
at
least
half
of
the
group
there,
we
probably
shouldn't
be
having
these
discussions
because
we're
leaving
out
so
many
of
the
stakeholders,
but
with
this
being
said,
I
think
that
there
is
a
clear
signal,
especially
early
on
that
if
we
can't
reach
quorum,
that
we
have
people
who
are
not
actively
engaged
enough
and
that
we
have
problems
with
engagement.
So
we
have
just
come
up
with
like
our
first
membership
requirement,
but
that's
kind
of
a
one-off.
A
Do
we
want
to
introduce
any
rules
around
membership
requirement
that
would
move
people
to
MIT
into
observer
status?
If,
for
example,
they
don't
attend
a
certain
number
of
meetings
or
don't
participate
in
the
issue?
Tracker
these
can
become
really
arbitrary
to
to
do,
but
a
good
example
would
be
if
we
have
someone
who
filled
out
the
the
doodle
but
does
not
attend
a
single
meeting.
Nor
do
they
participate
in
the
issue
tracker
for,
like
the
span
of
two
months,
should
they
mean,
should
they
maintain
their
ability
of
being
a
member
in
the
group?
A
Keep
in
mind
that
if
we
want
to
get
chartered
at
the
point
that
we
get
chartered,
this
group
is
going
to
have
like
for
lack
of
a
better
term
control
over
parts
of
the
of
the
codebase.
Any
one
person
within
this
group
could
descent
and
it
isn't
really
fair
to
the
people
who
are
active
to
have
someone
who
is
not
active
kind
of
just
show
up
when
they
have
business
that
they
want
to
be
able
to
control
it
kind
of
actually
having
people
in
our
consensus
model
that
are
not
actively
participating
hijacks.
C
Thinking
on
that
note
like,
if
we
have
like
right
now,
it
seems
like
there's
a
lot
of
stuff
that
really
needs
to
get
addressed
so
like
for
the
first
few,
like
maybe
like
the
first
I.
Don't
I,
don't
know
how
long,
but
for
a
while
we're
like
getting
settled,
maybe
having
stricter
membership
requirements
and
then
once
things
kind
of
settle
down
a
little
bit,
if
people
you
know
have
other
things,
they
need
to
work
on,
maybe
like
two
months,
doesn't
isn't
as
isn't
as
unreasonable.
At
that
point,
mm-hmm.
A
That
seems
fair,
I
also
think
I'm,
like
one
of
the
things
that
we
do
for
the
TSC
is
that
there's
a
combination
of
membership
requirements
and
it's
more
of
an
oar.
So
it's
like
if
you
were
like
it's
the
tracker
or
the
meetings,
and
you
need
to
actually
have
a
lack
of
engagement
in
both
in
order
to
be
considered
not
engaged.
U
Okay,
great
so
I
guess,
I
guess
the
concern
that
I
have
is
like.
There
are
certain
things
that
will
be
potentially
outside
of.
You
know
my
scope
in
terms
of
like
what
we
can
contribute
it
right,
but
I
mean
you
know
if
we're
not
necessarily
deep,
diving
on
you
know,
caching,
modules
necessarily,
but.
A
So
I
think
activity
is
not
defined
as
like.
You
need
to
be
active
on
everything
it's
just
like.
Are
you
participating
so
if
you're,
just
not
commenting
on
everything
and
you're
on
anything
and
you're
not
coming
to
any
meetings,
you're,
not
an
active
participant,
and
maybe
what
would
be
a
good
way
to
do
this
and
I'll
just
make
a
suggestion
and
then
Gil
I
see
your
hand
is
up.
A
Maybe
we
just
run
for
a
month
or
two,
and
then
we
just
as
a
group,
review
our
membership
review
participation
and
ask
people
who
have
not
been
active
to
move
to
an
observer
status,
and
if
that
causes
a
problem,
then
we
I
have
I,
have
a
bit
of
anxiety
around
having
it
be
such
an
undefined
thing
long
term,
and
it's
also
not
really
fair,
but
I.
Think
if
we
set
a
clear
expectation
as
a
group
early
on-
and
maybe
we
even
just
document
this
one
thing
like
in
the
first
two
months.
A
I
I
think
it's
a
good
suggestion,
although,
although
it's
a
bit
sensitive
to
ask
somebody
to
step
aside
because
they
haven't
been
participating,
that
is
why
I
I
prefer
a
harder
rule,
and
you
suggested
participation
in
meetings
or
in
the
issue.
Tracker
I
would
go
even
harder
I,
even
on
myself.
I
think
participation
both
is
necessary.
I
I
mean
just
attending
meetings
is
actually
pretty
easy,
but
the
real
work
is
going
on
in
the
issue
tracker
in
the
poll,
requests
and
I
think
that
is
where
participation
would
be
and
if
I'm
I'm
not
gonna,
be
there
I
would
willingly.
You
know,
step
down
and
be
just
an
observer,
but
I
think
we
should
set
these
and
not
be.
You
know
something
we
have
a
big
group
here.
It's
big
okay,.
A
Excellent,
so
with
that
being
said,
I
think
we
should
maybe
kick
this
conversation
back
to
the
issue
tracker
for
those
of
you
who
voiced
opinions
and
have
thoughts
on
this.
Please
contribute
that
contribute
to
the
conversation
there,
and
maybe
we
can
find
someone
to
write
up
some
text
that
we
can
include
in
the
repo
unless
anyone
wants
to
volunteer
to
take
that
as
an
action
item
right
now:
they're,
okay,
with
no
volunteers,
we'll
just
kick
it
back
to
the
issue
tracker
for
now.
A
The
next
thing
that
we
have,
since
we
only
have
ten
minutes,
left
I'm
not
going
to
spend
too
much
time
on
it,
but
I
open
an
issue
for
the
idea
of
an
online
module
summit.
There's
a
lot
of
content
here,
there's
a
lot
of
people
who
have
different
needs
and
different
thoughts,
around
modules
and
knowledge,
and
so
I
thought
that
you
know
it
could
be
a
really
great
knowledge
sharing
exercise
if
we
kind
of
planned
a
day
for
a
teleconference
where
we
can
take
turns
presenting
to
each
other.
The
topics
that
we
think
are
important.
A
This
can
be
recorded
and
put
on
YouTube,
so
those
that
can't
participate
can
get
it
later.
I
just
wanted
to
I
guess
quickly
see.
Does
anyone
object
to
doing
something
like
this
or
see
a
problem
with
it
cool?
Does
anybody
have
the
energy
or
motivation
to
take
lead
on
planning?
Something
like
this
I
can.
A
Awesome,
so
Brad
will
take
the
action
item
on
starting
to
plan
this.
If
you
have
content
ideas
of
what
you'd
like
to
do,
maybe
start
putting
it
in
there
and
then
Brad
I'll
follow
up
with
you
and
maybe
we'll
create
some
sort
of
like
CFP
proposal
process
or
just
like
a
form.
So
we
can
have
a
more
official
way
of
doing
it
and
we'll
start
scheduling,
content
and
then
figure
out
a
good
day
to
do
this
we
could
also
potentially
do
it.
Asynchronously
will
will
iterate
on
that.
A
Lighting
design
principles
is
guiding
design
principles,
overlapped,
I,
guess
that
doesn't
overlap
too
much
with
what
we
were
talking
about
before
with
scope,
but
I
mean
before
we
actually
dig
too
much
into
this.
Is
there
really
a
difference
between
our
guiding
design
principles
and
our
scope,
or
are
those
conflated
enough
that
we
should
maybe
merge?
There's
two
issues:
I.
F
A
Yeah
I
was
just
gonna
say
because
we
have
six
minutes
left
since
we
don't
really
have
consensus
on
there.
Maybe
kick
it
back
to
the
issue
tracker,
but
to
Brad's
point.
Maybe
it
makes
a
lot
of
sense
to
at
least
have
another
pull
request
separate
from
the
Bulls
one
that
outlines
guiding
principles
and
start
iterating
on
that
or,
alternatively,
include
the
guiding
principles
in
the
goals
document.
Brad.
Do
you
have
a
preference
on
that.
F
A
A
A
We
have
it
so
maybe
we
should
add
a
new
new
label
too
explicit.
Make
that
explicit
I
can
take
that
action
on
it
after
this
I
see
three
sign
offs
on
it
and
a
whole
bunch
of
comments,
since
it
is
something
that
we,
you
don't
have
a
lot
of
talking
to
do,
I
think
it
maybe
makes
sense
to
just
use
this
as
a
way
to
bring
it
up
to
anyone.
A
Okay,
excellent
Oh,
John
David
Dalton's
down
in
the
room,
Oh
Sean
awesome.
So
so
then,
with
that
being
said,
I
think
we
can
start
to
wrap
this
up
for
the
people
watching
live
on.
Youtube
I
am
in
the
chat,
saying
hi.
Does
anyone
in
the
YouTube
chat
have
any
questions
for
the
team
I'm?
Not
seeing
any
questions
for
those
of
you
who
are
interested?
We
have
six
people
watching
right
now
to
those
in
IRC.
Anyone
on
IRC
have
any
questions.
I,
don't
see
anything
so
congratulations.
Everyone!
A
A
And
okay
bedford
has
a
stand-up
guy,
yeah.
J
I
just
wanted
to
mention.
I
know
we're
probably
gonna
mostly
be
focusing
our
time
on
discussing
the
high
level
concepts
here
and
making
the
high-level
decisions,
but
if
people
are
interested
in
getting
involved
in
working
on
modules
and
node
core
there's
lots
of
places
that
the
existing
implementation
can
do
with
assistance
and
help
things
like
benchmarking
performance,
improving
the
tests.
Our
message
is
a
huge
one
that
we,
we
don't
have
very
good
error
messages
at
the
moment
and
so
there's
a
lot
of
areas
to
work
on
it
of
varying
difficulties.
A
J
D
A
Okay,
awesome,
if
you
could
throw
that
in
a
comment
into
the
PR
I,
think
that
that's
you
know,
that
would
be
a
good
way
to
make
sure
that
that
gets
iterated
on
okay,
great
I
want
to
thank
everyone
for
volunteering.
Your
time
here,
some
of
us
are
paid
to
work
on
open
source.
Some
of
us
are
not,
but
either
way
a
lot
of
us
still.
I
would
say.
A
Most
of
us
have
a
choice
of
what
we
decide
to
put
our
energy
and
time
into
so
I
personally
really
appreciate
every
single
person
who
is
donating
their
time
in
this
meeting
in
the
issues
and
the
pull
requests.
Thank
you.
We
all
have
a
shared
goal
of
making
javascript
better
and
making
a
better
user
experience
for
people
around
the
world
and
I.
Think
it's
pretty
exciting
that
we
get
to
work
on
this.
So
thank
you.
Everyone
for
a
really
successful
meeting,
I'm
going
to
turn
off
the
livestream
and
thank
you
again.