►
Description
Google Form for Questions: https://docs.google.com/forms/d/e/1FAIpQLSea-eYU11_GYrJJCAXPX7hUM-CWsDPgTdFt0Xse64OzU0OHRA/viewform
A
A
If
nobody
else
has
any
others
did
the
one
I
will
put
out
there
is
I
know
that
I
was
just
asked
to
add
a
meeting
to
our
calendar
for
next
Monday
at
2:00
Eastern,
Daylight,
Time
related
to
working
on
the
node
NGS.
The
discussions
around
you
know
merging
those
two
foundations.
So
if
you're
interested
in
participating,
you
know
here's
a
color
to
the
TSE
members
plus
anybody
else,
who's
listening,
that's
an
opportunity
to
to
get
involved
in
those
discussions.
A
That's
all
I
have
so
if
nobody
else
has
any
other
announcements,
we'll
move
on
to
the
items
on
the
agenda.
My
recommendation
is
that
we
start
with
twenty
three
one:
five
five,
since
we've
got
Raphael
here
as
a
guest
to
talk
about
that
one.
So
we
should
do
that
and
then
you
know
let
him
drop
off
if
he
wants
to
so
in
any
objections
to
that
No.
A
B
Okay,
it
goes
back
a
little
bit
a
while
a
little
bit
so
I'll
give
a
bit
of
background
on
myself.
I
have
roughly
20
years
experience
a
program
in
C++
have
been
trying
to
refresh
my
knowledge
with
what
now
is
referred
to
as
modern
C++,
which
is
supposed
us
from
2011
and
2014
in
2017,
and
the
upcoming
C++
20.
B
B
While
reading
and
reviewing
and
reviewing
and
learning
our
code
base,
a
discussion
came
up
between
me
and
Anna
around
to
subject.
It
originated
just
two
subjects:
the
use
of
the
of
auto
and
the
use
of
non
conferences,
ie
references
variables,
so
Anna
stated
that
the
common
rule
is
not
to
use
out
all
and
not
to
use
references.
B
B
Wouldn't
say
neatly,
but
I
asked
like
where,
where
is
that
stated?
Let's
start
a
discussion
about
that,
because
that's
kind
of
against
where
the
language
is
going
and
by
where
the
language
is
going
on,
using
as
reference
the
ISO
committee,
the
people
who
are
writing
books
about
best
practices
in
C++,
there's
a
very
interesting
project
called
the
scipios
par
score
guidelines,
which
is
a
living
document
in
github,
that's
written
by
her
father
and
be
honest
starstruck.
You
know
two
of
the
major
leaders
in
the
language
and
it
kind
of
breaks
down.
B
B
One
of
them
is,
for
example,
is
the
use
of
auto
auto,
as
for
those
doesn't
know,
tells
the
compiler
that
it's
the
variable
that
I'm
declaring
is
still
strongly
typed.
It
has
a
very
specific
type
known
at
compilation
time.
It's
just
that
during
initiation,
the
right-hand
side
has
a
definite
type,
and
so
the
compiler
can
automatically
derive
the
type
and
their
argument
is
we
already
do
that.
B
We
already
do
that
when
we
do
template
it
programming
and
we
say
template
type
name
T,
and
then
we
put
T
and
we'll
let
the
compiler
fill
out
the
rest
of
it
and
they
say.
Similarly,
there
is
the
use
of
Auto.
It
doesn't
give
the
compiler
any
new
information.
All
the
information
is
there.
It's
just
on
the
right-hand
side
instead
of
on
the
left-hand
side,
so
we
had
that
debate
in
in
a
different
PR
and.
B
B
B
B
B
The
wording
was
more
hard,
so
I
I
used
I
described
it
as
arbitrary,
because,
apart
from
this
very
a
subjective
way
of
looking
at
it,
there
are
no
real
example.
I
didn't
see,
any
references
I
was
looking
like.
Where
did
this
rule
came
from
I
didn't
find
any
you
know,
Anna
didn't
provide
any,
except
for
saying
this
is
how
we've
been
doing
it,
and
ever
since
then,
I've
been
trying
to
narrow
down
like
what?
What
we?
B
What
don't
we
like
about
reference
arguments,
so
there
are
places,
for
instance,
in
the
Google
style
guide
in
the
circuit,
in
the
C++
core
guidelines,
where
they
say,
for
instance,
references
as
arguments.
The
functions
don't
make
sense
in
a
lot
of
cases,
their
main
point,
their
main
strength
or
the
idiomatic
interpretation
of
a
non
conscious.
B
Reference
argument
is
when
you
want
to
pass:
what's
called
an
in/out
parameter
when
you
have
a
parameter
that
lives
in
an
outer
scope,
and
you
want
to
give
it
to
the
function,
to
use
to
change
and
then
essentially
give
it
back
to
you,
but
not
through
not
via
the
return
mechanism,
but
via
an
in/out
parameter,
and
both
the
C++
core
guidelines
and
the
Google
style
guides
say:
don't
do
that.
There
are
other
ways
to
do
that.
You
can
do
that
by
pointer.
B
B
B
My
point
of
view
and
I'm
gonna
be
a
little
bit
critical.
I
didn't
get
a
lot
of
counter
arguments
there
are.
There
are
people
who
are
agreeing
with
this
perspective.
I'm
I'm
agreeing
with
this
perspective,
I,
think
this
consensus
about
designing
api's
without
non
costs.
References
but
but
I
think
that
saying
don't
use
non
cons.
References
pointers
are
better
is.
B
It's
not
I,
don't
think
it's
the
right
thing
to
do
and
not
in
a
guy
not
like
as
a
rule,
and
the
guideline
is
something
that
we
want
to
enforce
later
and
something
we
want
to.
You
know
something
somebody
who's
new
I'm,
giving
myself
as
an
example.
Somebody
who,
just
you
know,
read
a
couple
of
books,
took
a
course
did
some
exercises
it's
coming
into
node.
He
wants
to
write,
he
wants
to
use
what
he
learned
and
then
we
come
and
tell
him
know
what
you
learned
is
wrong.
B
We
have
our
own
rule,
we
don't
have
a
good
justification
for
it,
but
don't
do
that
and
it
affects
our
code
and
that
a
lot
of
new
functionality
that
comes
in
through
libraries
and
a
lot
of
new
functionality
that
has
been
standardized
into
the
standard
library
uses
nonconference
--is
specifically
for
mutating
containers.
For
instance,
if
you
have
a
vector
of
values-
and
you
want
to
go
over
that
vector
and
mutate
every
value
or
you
want
to
search
and
mutate
different
things.
For
instance,
you
have
a
string
and
you
want
to
that.
That's
a
real
example.
B
B
D
So
I
mean
for
the
most
part
that
was
too
like
a
decent
overview.
I
mean
like
so
so.
A
couple
things
like
like
Rafael,
mentioned
that
we
didn't
provide
any
references
for
like
where
these
rules
come
from.
They
are
pretty
much
what
Google
does
and
while
Google
only
specifies
them
in
their
in
their
style.
Guide
for
for
API
is
for
functions
this
this
matches
with
their
with
the
style
that
they
use,
or
at
least
that
v8
uses
and.
D
Well,
I
I
mean
like
I
I
would
say
that,
like
while
I
I
get
where,
where
Rafael
is
coming
from,
and
everything
and
and
I
appreciate
the
effort
to
make
no
just
newcomer
friendly-
and
maybe
this
is
doing
this,
but
there's
also
like
a
lot
of
value
and
having
a
having
code.
That
is
easy
to
read
them
to
you
verify
is
correct
by
looking
at
it,
because
that
is
what
a
lot
of
reviewers
do
and.
C
E
Sorry
to
interrupt
I
was
just
thinking
like
we've
mentioned
a
great
deal
of
arguments
in
favor
and
against
using
these
non
conscious
references.
Would
it
not
be
helpful
if
we,
if,
if
we
listed
the
arguments
in
the
PR
more
explicitly,
rather
than
just
saying
that
pointers
are
almost
always
better
because
we've
just
we've
just
listed
a
whole
pile
of
reasons
why,
amongst
ourselves,
and
when
we
do
that,
then
we
can
we
can.
We
can
draw
a
conclusion
at
the
end
about
the
the
specific
cases
in
which
they
can
be
used
and
so
forth.
E
I
I
realize
that
the
staff,
the
style
guide,
will
be
more
verbose
as
a
result.
But
but
if
we
conclude
with
an
overarching
statement
based
on
on
previous
discussion,
then
then
we
can,
we
can
have
like
a
tldr
version
of
it
and
and
not
be
just
even
apparently
arbitrary
about
the
whole
thing.
So
you
know,
I
was
just
thinking
like
better
documentation
will
solve
this.
Is
that
not
true.
B
We
just
landed
a
couple
of
days
ago,
a
basis,
a
framework
for
our
style
guide.
That
says
we
we
strive
to
follow
the
sickness
past
core
guidelines
unless
they
conflict
with
the
Google
style
guide
and
unless
they
conflict
with
our
style
guide.
So
there
are
several
clauses
that
deal
with
this
particular
subject
in
both
of
those
guides
and
and
we
did
some
unfair,
posing.
B
We
took
the
the
part
of
the
style
guide,
they
talked
about
memory,
management
and
smart
pointers,
and
we
turned
it
into
a
list
of
references
and
like
a
tldr
of
what
we
recommend
in
doing
in
this
case.
I
was
very
I,
was
I,
couldn't
find
you
know,
really
good
arguments
about
not
using
about
the
general,
don't
use,
Malcolm's
references
and
also
to
say
that
this
is
how
v8
has
been
coding.
It's
also,
you
know
it's.
It's
not
completely.
B
You
know
straight
cut,
Google
and,
and
the
VI
team
has
been
trying
to
modernize
their
style
their
code
there
they
have
API,
they
have
actual
IP
eyes
that
use
non-count
references.
We
encountered
me
and
Emma
in
the
review
this
week,
like
an
easy
way
to
use.
Maybe
return
values
is,
is
with
Hong
Kong's
references
as
an
API
to
v8
I
had
very
short
conversation
with
people
in
in
Google
who
do
reviews
which
say
yeah.
B
G
G
B
I
don't
have
like
I,
don't
do
that
I,
don't
you
know
tell
people
don't
use
Hong
Kong's
reference
unless
you
know
that
they
make.
Oh,
that
looks
weird
there
are.
There
were
several
examples
with
that
and
when
I
was
writing
C++
for
nodes
a
couple
of
years
ago,
I
didn't
get
those
comments,
so
I'm
taking
Anna's
word.
B
B
B
B
B
So
the
number
of
people
who
are
actually
doing
reviews
is
kind
of
small,
so
we
don't
really
adhere
to
the
style
guide
that
we
already
have
and
the
barrier
of
entry
is
kind
of
high
because
you
don't
know
am
I
allowed
to
do
that.
Am
I
not
allowed
to
do
that.
So
in
that
sense,
it's
it
won't
be
introducing
a
mass
of
new
weird
code
into
our
code
base.
I,
don't
think.
B
H
H
If
we
are
going
to
choose
a
style,
I
think
we
should
basically
go
with
the
VA
style,
because
you
have
to
interact
with
the
API
a
lot.
It's
kind
of
weird.
If
you
suddenly
changed
the
the
the
interface
are
like
once
you
leave
the
VA
API
level
up
to
the
know
that
level
you
suddenly
change
the
style,
it
would
be
kind
of
weird
and
I.
Just
took
a
look
at
the
VA
guys
and
most
of
the
non
cons
reverses.
They
are
upward,
overload
operator,
low,
overloads,
most
was
trying.
H
They
still
use
pointers,
so
I,
don't
think
like.
We
should
just
point
out
that
pointers
are
always
not
preferred,
but
we
should
probably,
in
my
opinion,
we
kid
like
leased
out
different
occasions
like
in
and
out
parameters
which
values
and
use
specific
examples
that
allow
us
to
like,
in
turn
interact
with
vab
eyes
in
a
more
consistent
way.
I
think
that
will
make
the
code
easier
to
read,
see
that
that's
my
two
cents.
G
The
question
is:
if
we
deluxe
this
rule,
if
we
assume
that
we
have
found
that
just
the
facts
of
all
four
food
quests
clicking,
if
an
asset
as
assuming
that
we
can
relax
this
rule
and
I
appreciate
that
you
request
and
not
follow
this
rule,
what
can
we
change
in
our
existing
code
base?
That
would
improve
in
your
opinion,.
B
B
There's
the
new
pattern
of
for
range
of
a
for
the
trans
over
a
container
to
mutate.
It
a
lot
of
our
code
uses,
what's
called
range,
checking,
meaning
checking
that
the
iterator
runs
from
the
beginning
to
the
end
and
it
doesn't
cross
the
the
bounds
of
the
container
a
for
range.
Does
that
automatically
foreign
cannot
do
out
of
bounds,
manipulation
on
a
valid
container
to
mutate
that
container.
B
We
need
a
non-conference
there's
a
new
function
coming
in
sickness,
past
seventeen,
and
it's
already
implemented
in
a
lot
of
our
compilers,
that
that
is
called
for
each
that
can
do,
and
that
can
do
a
look
like
for
each
in
JavaScript
that
can
take
a
lambda
and
run
it
over
a
container
for
every
value.
It
needs
to
have
an
outcomes,
reference,
there's
the
contract
of
pairs
and
tuples,
which
group
parameters
together,
it's
much
easier
to
interact
with
the
output.
B
If
you
the
structure
this,
the
pero
tuple
with
noncoms
references
when
you
receive,
even
when
you
receive
a
pointer
from
a
function-
and
you
know
for
certain
that
the
value
cannot
be
null
which
is
sort
of
a
characteristic
of
a
reference.
Instead
of
a
pointer,
you
can
dereference
that
once
and
let
the
compiler
keep
track
of
that
variable
for
you
and
you
don't
have
to
pay
for
the
dereferencing
every
time
you
can
make
your
code
cleaner
and
more
correct,
because
you
explicitly
say
I
cannot.
This
call
cannot.
B
B
Don't
completely
agree
that
we
should
infer
what
the
people
that
wrote,
v8
were
thinking
when
they
use
certain
constructs
with
our
own
interpretation.
When
we
can,
you
know,
go
to
a
well-formed
reference,
such
as
the
Google
style
guide
and
C++
core
guidelines
and
say
when
I
use
an
unconstraint.
What
does
that
mean
if
that
function
takes
an
R
reference?
What
does
the
API
designer
tell
me
and
that
will
reduce
I?
Think
a
lot
of
the
you
know
weirdness
and
obscurity,
because
it
will
be
if
it
will
become
placed.
B
A
D
D
Not
references
in
api's
indicate
that
that
a
value
is
probably
going
to
be
changed.
I
have
that
API,
but
the
thing
is
that
is
just
like
just
about
passed
too
far.
Pointers
as
it
is
preferences
there's
also
a
concept
of
cloud
pointers
and
Tory
are
conferences
which
we
like
use
extensively
and
like
for
the
opposite
use
case.
So
I,
don't
think
that
distinction
is
actually
being
added
or
removed
from
from
our
API.
D
I
But
I
would
quickly
like
to
propose,
if
you
can
hear
me,
I
would
like
to
propose
this,
so
we
can
split
this
discussion
into
two
discussions.
One
is
documenting
the
current
style
guide
and
I
feel
confident
in
saying
that
our
current
structure
idea
is
to
follow
the
Google
side
right,
which
says
which
which
matches
up
with
what
Anna
has
posted.
If
there's
debate
about
the
style
guide,
let's
back
have
it
back
on
github
right,
so
we
should
go
and
what
we
have
now
and
whatever
modification
is
needed.
Let's
do
it
on
get
up.
B
So
I
I
would
don't
have
you
know
any
good
objections
to
that,
except
for
I'm.
Looking
for
references,
expensive,
direct
references,
for
instance,
there
is
a
comment
in
the
in
the
current
Google
style
guide.
That's
saying
that
the
plan
is
to
aggressively
update
it
as
the
language
progresses
and
if
we
have
in
our
style,
guide
references
directly
to
the
Google
style
guide
and
they
update,
we
get
that
update
transitively
and
automatically
so
I'd
rather
have
references
than
statements
in
our
guide.
C
You
do
have
another
item
on
the
agenda
and
there's
about
20
minutes
left
wonderful.
We
should
all
ponder
this
and
weigh
in
in
the
issue.
Tracker
and
I
do
like
I
do
like
Ali's
proposal.
I,
think
you
know,
references
can
be
added,
but
I
don't
know,
ask
mr.
they'll
and
with
the
references
it
would
be
nice,
but
it
can
also
be
added
later
and
if
you're
concerned
that
a
link
won't
be
updated,
I
guess
we
could
always
link
through
something
like
archive.org
or
something
else
that
will
keep
up.
A
A
B
A
final
word
a
bit
in
general,
so
it
doesn't
seem
to
me,
like
we
have
a
very
high
barrier
for
entry
into
our
cyclists
bus,
a
code
base
which
is
roughly
you
know
and
I'm
well
parking
it
like
half
of
our
code,
and
we
have
a
very
very
small
group
of
people,
were
maintaining
it
and
progressing
it.
I
would
like
to
see
that
change.
I
would
like
to
see
that
the
barrier
of
entry
being
lower
and
and
having
a
bigger
group
discussing
all
this,
and
thank
you
very
much
for
giving
me
the
time
and
listen.
J
Really
really
quickly
and
please,
if
anyone
disagrees
with
me,
please
feel
free
to
object,
but
I'd
like
to
request
that
this
potentially
get
kicked
off
to
a
like
a
subgroup
or
another
meeting,
rather
than
taking
it
to
the
TSC
meeting
in
the
future.
Because
I
feel
like
there
is
a
very
subset
small,
smaller
subset
of
people
that
have
the
skillset
an
interest
in
this.
J
C
C
This
was
put
on
the
agenda
by
sac
the
freon,
who
this
is
a
very
bad
time
for
it's
the
middle
of
the
night
in
in
India
right
now,
and
so
we
may
wish
to
push
this
off
to
next
wee,
but
maybe
just
people
can
make
a
point
to
look
at
it.
Yeah
hee,
hee
hee
feels
like
this
issue
comes
up
again
and
again
them
again
and
once
you
know,
we'd
like
to
achieve
a
resolution
on
it
and
I
do
think.
I
do
think
that
this
is
is
we're
worth
making
a
decision
on
I.
C
Do
think
that
this
is
something
that
the
status
quo
is
is
is
pretty
much
less
desirable
than
like,
3
or
4
possible.
Other
things
we
can
do
so.
If
everybody
could
look
at
that,
that's
priests!
You
don't
need
any
C++
knowledge
to
understand
that
I'm
happy
to
report
so,
but
take
a
look
at
that
one
I
don't
know
if
anybody
has
anything
they
want
to
add
to
that
b8.
Besides
that
I.
A
J
We
had
a
short
board
meeting
last
week,
mostly
going
through,
like
at
none
interactive
Leslie,
going
through
the
numbers
from
the
conference
of
them,
some
ones
that
are
interesting
to
share.
You
know
just
under
a
thousand
tickets
sold
and
I,
don't
remember
the
exact
numbers
that
have
to
get
up,
but
it
was
around
a
twenty
percent
growth
both
in
attendance
and
in
you
know,
funds
that
the
conference
raised
not
exactly
board
related,
but
you
know
we
announced
all
the
stuff
related
to
the
merger
of
the
Jason
node
foundation.
J
Just
the
week
before
the
conference,
we
helped
open
town
hall
last
week
and
the
meeting
that
has
been
a
weekly
meeting
joint
board
meeting
to
discuss
the
merger
we're
working
on
opening
that
up
and
starting
to
broadcast
it.
So
you
know
everyone
the
TSC
and
even
further
you
know.
All
members
within
the
org
are
invited
to
join
there's
a
new
repo,
nodejs,
slash,
bootstrap
and
inside
of
that
repo.
There
is
an
issue
which
is
issue
number
ten
I
will
drop
it
in
the
chat,
but
we
have
all
the
details.
J
In
there
the
meeting
is
Mondays
at
2:00
p.m.
EDT.
That's
11:00
a.m.
PDT.
There
is
a
conflict
with
another
groups,
meeting
we're
in
the
process
of
trying
to
figure
that
out.
But
the
main
idea
with
this
meeting
is
specifically
that
you
know.
One
of
the
big
feedbacks
that
we
got
at
the
collaborator
summit
was
that
it
felt
like
you
know.
We
have
too
much
of
an
innovation
cycle
where
things
are
kind
of
being
thrown
into
a
black
box,
and
that's
you
know
not
the
intent
of
how
we
were
designing
things.
A
J
So,
two
weeks
ago,
as
well,
we
landed
a
minimal
kernel
for
modules.
This
is
a
subset
of
behavior
that
we
agreed
would
exist
in
all
potential
modules
implementations.
So
it's
really
exciting
that
we
got
that
landed
in
our
fork.
You
can
find
that
for
Kanodia,
slash,
equi
script
modules,
some
of
the
big
things
with
it
is
like
you
know
you
pretty
much,
can
import
es
modules.
J
In
the
user
experience
of
create
require
function
or
how
the
URL
API
is
a
different
API.
You
could
potentially
use
URL
of
file
strings.
We
don't
necessarily
have
an
answer
on
all
these
things,
but
it's
you
know
what
we're
focused
on
right
now
and
then
we're
also
doing
a
focus
on
extensible
loaders
that
could
be
used
for
kind
of
building
out.
Any
of
the
other
contentious
features
that
we
have
I
think
we
have
our
next
meeting
next
week.
J
A
Okay,
next
in
the
list
is
napi
I,
guess
no
major
things
true
report
on
there
other
than
gonna
be
a
workshop
at
node
coffee
you
and
there
was
some
good
discussions
on
at
the
collaborator
summit.
One
of
them,
you
know,
hopefully
bringing
us
a
little
bit
closer
to
the
electron
team.
In
terms
of
you
know,
we've
had
some
people
report
that
it's
been
at
least
on
some
platforms.
Modules
haven't
worked
there
and
I
think
you
know.
We've
closed
the
loop
in
terms
of
hopefully
being
able
to
address
some
of
those
issues,
OpenSSL
evolution
so
broad.
F
H
A
J
We
covered
it
mostly
in
the
board
related
stuff,
but
you
know
just
we
stuff,
I
didn't
mention.
We
had
a
really
great
long
session
at
the
collaborator
summit.
It
ran
for
almost
a
day
and
a
half
you
could
see
in
that
bootstrap
repo,
which
is
kind
of
the
result
of
that
there's
an
open
issue
right
now,
issue
number
11
with
the
governance
breakout
session
takeaways,
and
that
has
notes
on
all
these
stuff
that
we
had
collected
around
there.
J
Aside
from
that,
you
know,
it
seems,
like
the
focus
of
governance
has
maybe
shifted
a
little
bit
away
from
the
governance
of
the
node.js
project
to
the
to
the
governance
of
a
joint
foundation.
These
do
overlap
when
we're
thinking
about
like
what
does
nodes
representation
look
like,
but
I
think.
Perhaps
we
should
have
a
discussion
at
some
point
about
about
this
particular
piece
and
if
we
want
to
be
making
sure
that
we
make
an
explicit
difference
between
foundation,
governance
and
project
evidence,
that's
it
for
now.
Okay,.
A
I
Nothing
substantial
to
add.
We
didn't
have
a
diagnostic
work
session
at
the
collaborate
summit
and
there
was
discussion
around
the
proposal
is
in
contact
formalization.
So
that's
a
PR
in
the
diagnostic
working
group
and
might
be
useful
big
for
people
to
take
a
look
at
and
see
how
it
relates
to
async
hooks
yeah,
that's
about
it.
I
think.
A
Model
might
make
sense,
you
know
not
that
that's
the
agreement
or
consensus
or
anything
like
that,
but
if,
if
you're
interested
in
async
hooks
or
what's
there
already-
or
it's
definitely
worth
looking
at
that
because
it
it's
it's
not
well
anyway,
it
just
suggests
that
there
might
be
other
other
API.
So
it
would
make
sense
right
and
then
final
open
web
standards.
J
That
one's
me,
too,
we
had
a
big
meeting
at
the
collaborators
summit
as
well.
Talking
about
all
these
different
things,
I
think
with
the
amount
of
stuff
that
I've
been
focusing
on
hey
Joey,
since
you
are
leading
that
session
and
have
a
really
great
interest
in
this.
Would
you
be
interested
in
taking
over
as
champion
on
the
open
standard
stuff
or
at
least
sharing
it
I'm,
not
sure
if
you're
in
there
sharing
it
already?
My
apologies,
if
you
are
but
I
just
feel
like
I'm
talking
too
much
so
I'd
like
to
share
the
floor.