►
From YouTube: Next 10 years of Node.js - July 16 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
the
follow-on
to
the
next
ten
years
of
nodejs
session
that
we
held
at
the
at
the
collaborator
summit.
We
had
some
really
good
discussion
there
and
you
know,
but
it
was
longer
longer
discussion
and
we
could
possibly
fit
into
the
two
hours
that
we
had.
So
this
session
is
the
first
follow-on
and
I
had
a
proposed
agenda,
which
was
to
talk
about
logistics
schedule
so
forth.
Talk
about
some
initial
priority
streams
that
we
would
work
on.
As
you
know,
there's
lots
of
different
topics
in
the
the
original
box.
A
A
So,
but
you
know
I
think,
review
that
and
agree
that
that's
where
we're
gonna
continue
to
work
and
then
one
of
those
was
you
know,
I
think
we
had
a
few
different
topics,
but
my
take
was
they
all
sort
of
related
to
technical
evolution
and
so
I
thought
we
could
sort
of
continue.
Those
discussions,
as
in
in
the
time
that
we
had
left
that
sound
good
to
people.
B
A
I
will
take
silence
yaza
as
let's
move
forward,
so
the
first
one
was
on
the
logistics
and
schedule
kind
of
like
how
do
we
want
to?
You
know,
continue
this
discussion,
I.
Think
Mateus,
you
were
you
know
some
of
the
questions
you
you
had
were
hinting
at.
You
know
we
could
set
it
up
like
one
of
our
teams
are
working
groups
where
we
have
like
regular,
scheduled
meetings.
We
could
have
something
in
the
calendar.
Err
that
then
Auto
generates
issues
that
kind
of
stuff
I
don't
know.
A
A
Think
I
can
volunteer
to
calendar
laughs,
Auto
generation
that
won't
be
too
hard
to
do.
I
guess
the
the
the
question
would
come
back
to
then
similarly
related
to
meeting
times
as
logistics
I
tried
to
pick
this
time
as
a
as
a
time
this
kind
of
between
Pacific
and
European
time,
but
I,
don't
know
how
how
well
that
will
necessarily
work.
B
A
A
A
Like
I,
almost
wonder
if,
like
I
mean
it's
the
yeah,
the
original
art,
because
the
original
idea
was
that,
like
you,
know
a
summit
where
we
could
come
together
and
you
can
make
a
lot
of
progress
because
you've
got
everybody
together
for
a
substantial
amount
of
time,
the
longer
we
sort
of
drag
it
out,
the
less
you
get
of
that
momentum.
But
on
the
other
hand,
you
know
not
being
at
a
summit.
People
do
have
all
the
other
polls
on
their
time
and.
A
A
A
A
A
A
I'm
in
that
session,
you
know
we
we
spent
a
little
bit
of
a
little
bit
of
time
on
looking
at
what
were
the
things
that
made
no
Jes
successful
in
the
last
ten
years.
What
were
the
key
values
that
supported
that
success
and
what
worked
in
the
management
of
project
and
what
didn't
you
know?
We
didn't
have
a
ton
of
time,
but
you
can
look
at
look
through
that
issue.
In
terms
of
you
know
the
things
that
we
summarized.
A
What
did
not
was
things
like
working
groups,
consensus
seeking,
although
there
was
the
comment
about
how
we
can
be
more
efficient
on
that
front,
how
we
handle
larger
changes
might
still
be
a
bit
of
a
challenge
and,
getting
you
know,
good
diversity
of
people
in
the
meetings
and
time
zones,
I
think
was
also
seen
as
a
challenge
terms
of
you
know.
Maybe
what
that
didn't
work
so
well.
A
We
then
got
into
again
looking
in
the
in
the
through
the
file.
We
got
into
some
key
technology
trends,
so
things
like
typescript
was
some
discussion
about
no
just
supporting
browser,
api's
networking
standard
static
and
of
ahead
time,
compiling
so
things
around
waz
and
promise
based
api's,
better
diagnostic
debugging
traces.
A
As
some
of
the
you
know,
the
key
technical
trends
that
are
important
to
the
future
success,
that
was
one
of
the
things
we
sort
of
voted
on
and
started
to
dig
into
and
I
think
it's
something
we
can
continue
to
talk
about
this
session.
The
second
one
on
the
list
was,
we
talked
about.
Should
we
have
a
roadmap
priority
list
or
something
along
those
lines?
A
A
Just
paraphrasing
someday,
you
know
there
was
a
bunch
of
interesting
discussions
in
there
about,
like
you
know,
how
do
we
get
things
and
how
do
things
go
into
core
versus?
Not
you
know,
or
just
you
know,
there's
a
small
core,
a
small
core,
not
small
car,
there's,
also
the
what
is
it
you
know.
Are
there
what
that
mean?
Other
are
there
things
that
you
know
maybe
want
to
be
in
the
note
project,
but
don't
necessarily
need
to
be
in
core.
A
Should
they
be
delivered
some
other
way
like
through
a
you
know,
libraries,
or
something
like
that?
That's
so
that
I
think
is
like
the
very
high-level
summary
and
I'd
recommend.
If
you
want
to
get
back
to
the
details
you
can,
you
know
was
recorded,
so
you
can
go
back
and
watch
the
session
I
proposed
for
today
that
we
look
at
the
agenda.
As
the
you
know,
it's
we,
a
number
of
those
came
down
to
looking
at
like
technical
evolution.
A
So
what
are
the
key
technology
transfer,
nodejs
priority
themes,
strategic
investment
areas
and
I
guess
maybe,
where
we
can
start
today,
is
like
if
we've
agreed
that
there's
some
key
technology
trends,
how
what's
the
best
way
to
surface
those?
You
know
you
know
and
capture
them
and
sort
of
communicate
them
and
so
I
listed
in
the
you
know.
A
This
is
the
the
potential
deep
dive
area
for
today,
which
is
you
know,
continue
our
discussion
on
key
technology
trends
and
nodejs
priority
themes
for
teaching
investment
areas,
priorities
of
consistent,
which
sees
hierarchy
priorities
and
what
gets
into
core
I'd
suggest.
We
start
with
the
second
one
which
is
like
how
do
we
think
we
should
capture?
A
You
know
what
we
think
is
important
for
the
project.
What
should
be
focus
areas
like?
I
I'm
not
necessarily
you
know.
A
road
map
that
says
feature
x
is
going
to
be
in
release
y,
but
the
first
starting
point
would
just
be
even
like
what
are
the
themes
that
are
important
and
that
we're
focused
on
does
that
make
sense
to
people.
D
D
A
That's
good
for
discussion.
What
I
thought
here
is,
like
you
know,
can
we
come
to
recommendation
as
to
what
we
think
we
should
have
for
the
you
know?
In
the
end,
that's
gonna
be
part
of
the
node
core
repo
or
the
because,
because
this
really
needs
to
be
integrated
like
it
can't
be
like
hey,
some
small
subset
went
off
and
thinks
these
are
the
important
it's
like
it's
got
to
be.
This
is
what
the
project
has
decided
is.
It
is
important
and
it's
communicating
that
right.
A
E
E
You
know
what
it
means
going
forward
in
the
next
ten
years
to
continue
to
collaborate
and
work
on
great
initiatives
together,
including
broader
standardization,
of
certain
aspects
of
what
it
means
to
build
a
node
project
right
so
package,
maintenance
and
and
those
sorts
of
initiatives
and
projects
are
sort
of
the
things
that
I
see
more
more
standardization
and
even
changing
for
us.
Changing
the
governance
of
sort
of
how
we
we
work
and
hope,
hopefully
including
more
people
to
come
to
the
table
with
our
project,
specifically,
is
kind
of
the
hope
for
for
that.
D
E
It's
you
know,
since
I've
got
to
since
I've,
you
know
been
maintaining
NPM
as
of
last
July,
that
sort
of
being
the
the
hard
work
is
cleaning
up
and
trying
to
organize
the
the
project
in
a
way
that
will
hopefully
set
us
up
for
long
term.
Success
and
yeah
and
I
think
there's
a
lot
of
work
to
be
done
around
standardization
and
and
changing
governance
of
our
project
and
yeah.
We've
got
some
great
great
people
involved
now
with
the
project,
so
yeah
yeah.
E
There
so,
like
our
roadmap,
is
not
a
hundred
percent
like
external,
which
is
not
not
great
right.
We've
tried
to
do
a
good
job,
etter
job
at
communicating
like
what's
coming
down
the
pipeline.
We
reason
give
project
boards
before,
but
there's
no
real
Road
mapping
tool,
which
kind
of
doesn't
communicate
well
sort
of
the
longer
initiative.
Like
the
more
longtail
initiatives.
We
have
been
using
Zen
hub
a
bit
for
that
kind
of
stuff
to
get
those
graphs,
but
it's
not
exposed.
There's
no
transparency
there
to
the
community.
A
Bullets
anyway,
it's
I
always
figure
it's
worth
asking.
If
there's
something
we
can
look
at
and
say
hey,
should
we
just
adopt
that
brett
bradley
I'd
go
back
to
you
know
you
were
talking
about.
You
know
priority
theme
or
sorry
constituents
or
priority
of
consistencies.
I
think
you
were
talking
about
yeah.
F
So
this
is
actually
documented
within.
I
think
it's
the
HTML
spec
itself
under
the
design
infrastructure,
and
so
currently
we
don't
really
have
any
prioritization
on
what
makes
a
feature
a
good
fit
for
nodes
core
right.
We
also
don't
have
any
sort
of
guidance
on
what
a
feature
needs
to
focus
on
right.
A
F
We
get
a
variety
of
responses
to
PRS,
which
are
somewhat
conflicting
if
you
look
at
them
as
a
whole
for
the
project,
some
PRS
are
claiming
that
performance
is
the
most
important
thing
to
a
specific
API,
while
others
are
acknowledging
that
they
are
not
a
incredibly
performant
api,
but
they
are
a
useful
API
and
we
do
these
very
ad
hoc.
The
priority
of
constituencies
is
basically
a
rough
guideline.
F
Of
course,
there
will
always
be
exceptions
or
conflicts
within
it.
They
states
things
like
users
should
be
valued
over
implementation
over
performance
and
things
like
that,
and
it
gives
just
a
guideline
that
when
we're
having
these
discussions,
we
can
state
that
one
argument
should
have
a
higher
priority
than
a
different
argument
right
now,
all
arguments
are
treated
equally,
and
that
means
that
when
we
encounter
a
blocking
scenario,
because
two
things
are
in
conflict,
we
don't
have
a
way
to
kind
of
argue
about
what
is
best
for
the
project
right.
A
A
Okay,
so
it's
almost
like,
like
I,
can
see
that,
like
you
know,
in
terms
of
what
our
gap
maybe
is,
is
we
don't
have
like
the
mission
statement,
then
from
that
you
could
see
you
could
have
this
priority
like?
What
are
we?
You
know
the
mission
being.
What
are
we
trying
to
accomplish?
Oh
and
then
the
you
could
have
that
priority
of
constant
constituency's,
which
kind
of
says
and
as
we
work
on
that
mission,
this
is
what
we
think
the
order
of
like
you
know
we
have.
A
This
is
important,
but
you
know
not
quite
as
important
as
this
other
thing
and
so
forth,
and
then
below
that
you
could
see
I,
don't
know
I'm
just
sort
of
brainstorming
like
we
could
see
a
set
of
you
know
not
and
maybe
I'm
just
mapping
out
the
standard
like.
Then
you
could
have
goals
to
say.
Okay
now
this
is
what
we're
trying
to
achieve
like
these
are
these,
are
you
know
not
more
specific
goals
like
we?
A
F
So,
while
the
experience
of
the
import
maps
themselves
are
kind
of
poor
and
the
performance
is
the
optimization
that
they're
doing
they're
doing
it
in
order
to
get
kind
of
this
other
goal
accomplished
of
a
better
user
experience,
so
they
they're
able
to
prioritize
based
upon
the
end-user
experience
rather
than
a
tooling
experience.
For
example,
right.
E
A
F
A
Like
and
so
that-
and
you
know
and
and
do
that
in
a
way
that
it
influences
you
know
the
goals
of
the
project,
the
direction
of
the
project,
you
know
I'm,
just
picking
that
at
that
you
know,
maybe
not
the
thing
but
like
any
anything
like
that
like
if
we
think
there
is
something
strategic
to
success
going
forward.
How
are
we
gonna
capture
and
communicate
those
things.
G
Question-There,
you
know
if,
even
if
we
have
these
things,
I
mean
this
is
an
open
source
project.
People
usually
work
on
things.
They
find
interesting
and
fun
like
if
you're
at
a
company.
These
priority
lists
makes
more
sales.
That's
because
that's
where
you
allocate
your
resources
that
you're
paying
for,
but
that's
not
the
kind
of
resources
we
have
in
this
kind
of
project,
it's
more
like
what
the
people
think
is
fun
and
what
the
people
find
interesting,
a
priority
list
of
things.
How
does
that
affect
that?
Well,.
A
A
D
Guess
another
good
point
is
that
if
someone
does
want
to
work
on
a
specific
feature,
they
can
refer
to
that
list
to
see
if
it's
likely
to
be
enabled
and
merged
in
without
without
because
at
the
moment,
the
only
time
you
find
out
that
your
features
not
wanted
is
when
it
gets
blocked
being
merged
into
core
list
would
serve
as
a
kind
of
check.
The
yes
I
want
to
work
on
this
and
yeses.
What
nodes
kind
of
aiming
for
and.
C
And
I
think
even
you
know
extending
that
if
we
kind
of
don't
lock,
this
down
is
like
you
know:
okay,
we've
done
this
and
we're
done
but
more
trying
to
approach
it
as
we
published
this,
and
you
know
we're
open
to
adding
things.
I
think
that
that
also
helps.
In
that
case,
you
know,
instead
of
having
to
get
blocked
once
you've
done
the
work,
you
can
kind
of
PR
it
to
the
list.
If.
D
C
Gets
blocked
on
that,
then
you
can
no
cool
I'm
not
going
to
waste.
My
time
doing
this
work,
which
is
like
one
of
the
pieces
of
feedback,
I
personally
heard
from
a
lot
of
folks
who
are
outside
of
core
that
they
PR
something
and
it
gets
shot
down
for
X
reason
and
having
that
proof
of
it
being
on
the
list
and
being
something,
that's
validated
would
actually
help
decrease
that
barrier.
Yeah.
A
I
think
it's
like
right.
It's
it's
highlight
like
and
again
it's
got
to
come
back
to,
we've
got
to
believe
there
are
things
or
strategic
right
and
if
we
believe
that
you
know
this
is
important
to
our
success,
then
as
tyranny
says,
it
helps
people
identify
areas
where
you
know
the
the
project
has
said.
Oh,
this
is
strategic,
so
so
contributions
that
move
that
forward
should
be
better
received
than
something
that
is
like.
F
Would
go
a
little
bit
further,
even
saying
that
it's
not
just
the
authors
of
PRS,
but
people
reviewing
things
could
have
a
better
sense
of
what
we're
aiming
for
right
now
when
you're
reviewing.
You
often
take
a
very
personal
viewpoint
to
what
you
want
to
see
in
core,
and
so
we
can
have
things
blocked,
because
we
state
that
it
shouldn't
be
in
scope
of
node.
But
if,
if
there
is
a
project
kind
of
list
of
things,
we
do
want
to
see
a
node,
we
could
actually
stay.
F
You
may
personally
not
want
it
in
node,
but
it
appears
to
be
something
that
the
node
project
is
working
towards
as
a
whole.
So
we
do
have
existing
examples
of
this.
We
actually
removed
extension
list
file,
support
from
our
ES
module
loader,
because
we
wanted
to
fix
a
problem
with
web
assembly,
and
so
that
was
a
rather
tough
decision.
We
ended
up
dropping
support
for
something
because
we
knew
in
the
future.
F
Well,
as
the
modules
working
group,
we
felt
that
it
would
be
important
to
support
web
assembly
and
we
didn't
have
a
good
story
for
it.
So
it
kind
of
also
goes
in
the
way
of
it
lets
you
review
things
in
light
of
what's
coming
up
ahead,
so
you
don't
introduce
features
that
are
gonna
hurt
you
later
on
I
I.
C
Huge
+12
that
Bradley
III
a
scene
that
what
you're
talking
about
again
in
the
context
of
like
contributors
being
feeling
and
welcome
or
being
feeling
like
they
got
shut
down
unduly
by
like
a
single
objector.
That
is
a
huge
thing
and
I
think
having
that
validation
is
a
good
way
to
kind
of
help
address
that.
C
Additionally,
you
know
I
think
this
also
potentially
helps
address
one
of
the
pieces
of
feedback
that
I've
heard
and
that
we
we
push
hard
against
in
the
past
or
past,
which
is
like
no
doesn't
have
a
roadmap
and
I
feel
like
we're
pretty
intentionally
not
having
a
roadmap
and
I.
Think
that,
while
we're
not
gonna,
have
a
roadmap,
I
think
that
this
helps
at
least
give
a
proposed
roadmap
or
proposed
vision,
which
is
what
people
are
kind
of
looking
for
in
a
road
map
and
it
kind
of
solves
the
thing
of
here's.
C
What
we
want
to
do
we're
not
committing
to
this
fully,
but
these
are
like
the
things
we're
interested
in
doing
as
a
project
and
that
kind
of
gives
people
a
way
to
rally
behind
certain
things.
So
it
helps
Abbas
prioritize
certain
features.
If
one
is
something
that
are,
you
know
large
amount
of
the
ecosystem
really
once
that
helps
us
prioritize
and
have
have
a
signal
that
also
helps
honestly
to
the
point
you
know
that
was
being
addressed
a
bit
earlier
is
full
transparency.
C
C
So
it
helps
justify
people
be
able
to
say
to
their
can
their
company
hey
I,
want
to
go
ship
this
in
node
and
then
that
they
can
do
that,
which
I
think
is
at
least
how
node
works
now,
and
maybe
this
is
something
we
want
to
change,
and
that's
fine,
but
at
least
how
work
node
often
works
now.
I
think
that
that
is
a
beneficial
thing
to
be
able
to
give
people
justification
to
be
able
to
come
work
on
the
project
as
part
of
their
work
time
and
be
compensated
for
that
work
through
their
employer.
A
A
You
know
we
work
on
features
and
they
kind
of
get
in
when
the
when
we've
got
them
done,
which
and
I
think
that
that's
work
then
that's
fine.
This
is
more
about
the
what's
our
vision
and
how
do
you
align
the
work?
That's
going
on
with
that
that
the
collective
collective
vision
and
I
think,
like
you
know,
tyranny
identified
a
few
things
that
that
you
get
out
of
that
is
that
you
know
people
can
point
that
the
work
they're
doing
is
aligned
with
the
vision
that
that
vision.
A
You
know
in
theory,
helps
you
know,
business
goals
as
well
and
even
like
I
think
you
know
the
the
was
and
one's
a
good
example
where
I
saw
call
and
ask
and
putting
out
a
question
that
said
well,
hey
is
wasn't
important
to
note.
You
know
should
I
keep
working
on
this
and
you
know
I
think
it
kind
of
helps
answer
some
of
those
questions
as
well.
So.
A
C
A
C
A
C
Think
that
having
this
as
a
thing
like
committed
to
core,
is
you
know
I
guess,
ironically,
you
know
we're
committing
to
it,
to
some
extent
that
this
is
a
thing
that
we
want,
and
you
know
by
literally
committing
it
into
core
I,
think
that
helps
solidify
our
assertion
and
it
also
like
you
know
if
someone
comes
in
and
it's
like
I
want
to
contribute
to
note.
Oh
here's,
this
file
with
a
bunch
of
things
that
are
like
you
know
things
that
they
would
like.
C
H
Michael
I
want
to
bring
up
a
point.
You
know
I
liked
reading
his
point,
but
I
was
thinking
more
in
the
terms
of
having
a
visual
task
board
or
something
like
that
which
we
can
now
and
get
up.
You
know
why
don't
we
have
something
like
that
which
people
can
just
go
and
see
like
okay?
What
are
the
new
features
that
are
there
and
have
like
a
file
attachment
to
the
features
that
give
a
bit
more
descriptive,
like
you
know,
like
a
high-level
overview
kind
of
thing.
A
C
C
It
it
is,
we
we
as
an
organ
in
terms
of
like
run,
managing
everything's
through
version
control
and
I.
Think
sticking
to
that
and
making
going
through
it
in
a
way
that
is
familiar
to
everyone.
Who's
been
here
for
a
long
time
and
who
is
coming
into
the
project,
is
going
to
be
the
way
that
we
have
find
most
success
of
this
right.
G
A
little
bit
static,
like
I,
think
it
just
just
gonna,
be
a
few
people
that
actually
care
about
this
document
that
will
actually
get
expressed.
You
know
the
opinions
and
what
they
feel
is
important.
I,
don't
have
any
better
ideas,
but
some
companies-
you
know,
let's
say
you,
create
a
request.
Then
anyone
can
go
in
and
votes.
You
know
a
thumbs
up
that
they
think
this
request
is
important.
That
way
capture
as
much
feedback
as
possible.
On
the
on
that
specific,
you
know
strategic
initiative
or
whatever,
because
that's
important
for
me,
we
have
a
document.
C
Guess
to
that
point
and
kind
of
backtracking
or
undoing
what
I
just
said
about
you
know
it.
Having
is
a
document.
Github
does
have
their
new
discussions
feature
which
includes
up
voting,
and
so
you
can
have
a
category
and
we
could
have
a
category
for
that,
and
then
we
could
just
use
the
gate
of
API
to
pull
that
stuff
into
a
doc
and
automatically
update
that
if
we
want
to
like
automate
that
and
have
that,
be
like
a
more
static
doc
or
a
dynamic
and
unofficial
doc.
C
C
You
know
commit
something
in
or
post
something
like
have
it
be
on
top
of
that,
maybe
as
an
additional
path
to
getting
stuff
in
of,
like
you
know,
some
random
person
comes
in
and
says,
like:
hey
I
want
typescript
support
by
default
in
yes
or
in
in
our
you
know,
loader
and
I
doubt
we're
gonna
do
that.
But
you
know
if
that
gets
you.
Five
hundred
thousand
votes
like
maybe
that's
something
we
should
consider,
is
something
to
listen
to
you
from
our
ecosystem.
C
A
A
A
It's
important
to
have
a
path
for
people
to
suggest
you
know
it's
the.
How
do
you
suggest
something
new
that
gets
into
the
things
that
are
important
to
the
future
of
node
and
how
does
how
do
we
gain
enough
input,
collective
agreement
that
they
are
important
right
because,
like
the
typescript
example
could
be,
we
could
say
well
type
scripts?
You
know
it's
it's
gaining
popularity,
but
could
we
just
ignore
it
and
node
will
succeed?
A
Maybe
right
and
you
could
make
that
decision
or
you
could
say
no,
no,
you
know
node
will
be
successfully
more
successful
if
we
provide
a
good
experience
for
typescript
developers.
Therefore
we
should
you
know,
do
XY
and
Z
right
and
then,
when
that
request
comes
in
then
that
sort
of
has
a
sorry
there's.
G
Another
aspect
of
this
is
that
there's
different
levels
here,
like
we
have
the
TSA
with
collaborators
we
have
contributors
and
we
have
users
yeah
most
specific
order,
they're
of
importance,
but
but
who
gets
you
know
who
votes
and
who
gets
to
create?
The
actual
you
know
requests
anybody
on
that
list
or
you
know
how
do
we
separate
that
I.
A
Think
the
like
okay,
it
can't
be
a
strictly
voting
thing.
I
think
like
the
up
voting
would
be
input
into
you
know
we
can't
tell
like,
as
you
as
you
were
mentioning
earlier.
We
can't
tell
people
to
what
to
work
on.
We
can't
force
people
to
think
something
is
important
when
they
don't
believe
that,
so
this
will
only
actually
be
helpful
if
it
reflects
what
the
project
as
a
collective
believes,
is
important
to
the
future.
A
So
I
think
I.
Think
input
from
end-users
makes
a
lot
of
sense,
but
it's
got
to
be.
You
know
the
the
collaborators
who
have
said
this
is
what
we
believe
from
all
the
information
that
we
have.
This
is
what
we
believe
is
important
to
the
project
and
what
we
think
we
we
need
to
do
to
make
sure
we
continue
to
be
successful.
A
So
I
think
yeah
I
mean
I
think
it
would
be
interesting
like
we
could
spend
a
lot
of
time
on
the
processes,
but
I
think
it
would
be
useful
to
come
up
with
work.
You
know
one
of
the
early
things
we
could
try
and
achieve
is
like
what
would
that
file
look
like
and
what
would
be
some
initial
contents,
because
I
think
making
it
tangible
on
that
front
would
help
to
get
more
discussion,
input
and
so
forth.
Right.
C
I
A
I
C
A
We
prioritize
this
over
that,
but
like
it's
trying
to
get
across
in
some
senses,
those
are
trying
to
get
it
across
technical
and/or,
other
types
of
values
that
inform
the
decisions
in
the
project
and
I
think
we
have
those
it's
just
I,
can't
think
of
where
I
would
go
to
learn
about
those
right
today
and
then
you
know,
that's
that's
almost
a
first
level
and
then
you
know
the
next
level
is
and
what
are
the
important
technology
technology
areas
and
evolution?
You
know:
what's
what
are
the
evolutionary
things
that
we
think
are
important
to?
A
That's
what
I'm
thinking
like
I
think
we
would
want
like
I,
can
totally
see
it
constitute
consistencies
or
priorities
is
for
the
sort
of
first
level
that
says
as
a
project.
This
is
kind
of
our
top
level
values
below
that
these
are
the
things
we've
identified
in
alignment
with
those
values
that
are
important
and
key
to
this
to
future
success.
A
So
it's
I
think
then
it's
like.
Maybe
we
can
think
about
that.
I
mean
we're.
Almost
we've
got
four
minutes
left,
but
I
think
what
would
make
sense
to
think
about
before
the
next
meeting
is
like
if
we
were
to
propose
adding
two
or
three
files
to
the
root
of
core,
what
would
they
be
and
what
would
the
contents
be
right,
like
you
know,
one
could
be.
C
A
G
C
C
We've
outlined
that
pretty,
at
least
from
the
folks
who
have
been
speaking
throughout
this
I
think
we've
kind
of
addressed
that
it
should
have
I
assume
some
kind
of
you
know
intro
to
what
it
is
values
of
the
project
and
then
specific
domains
and
things
that
we'd
like
to
see
within
the
next
ten.
You
know
till
the
ten
years
and
those
can
both
be
lists
and
then
that's
kind
of
it
or
from
you
know
again
from
right.
Let's
discuss
so
far,
I.
C
Well,
so
I
agree
that
they're,
different
and
I
think
one
informs
together.
I
think
values,
inform
and
I
do
think
we're
gonna
try
to
avoid
the
phrasing
or
the
approach
of
a
road
map
and
more
ideals
of
like
here's.
What
we'd
like
to
do
and
explicitly
avoid
it
being
a
road
map,
because
we
we
are
allergic
to
to
Road
mapping
present
project.
Unfortunately,.
G
C
A
Yeah,
so
yeah
I
think
we
have
some
some
content
there.
We
can
put
into
that
issue,
but
I
think
with
there's
still
lots
of
discussion
before
we'll
finalize
it,
but
putting
that
in
as
a
starting
point,
I
think
those
things
can
kick
it
off.
Okay,
so
that
that
sounds
good
and
we're
pretty
much
on
time.
But
our
first
output
of
this
discussion
group-
or
this
will
be
that
file
open
an
issue,
discuss
the
content
of
that
file
and
what
the
name
might
be
and
then
okay.